Supabase self-host etmek gerçekten daha ucuz mu?

Kimler için?

Supabase kullanan ekipler, ajanslar ve PostgreSQL tabanlı backend kurmak isteyen geliştiriciler.

Başlamadan önce

Mevcut proje listesi, kullanılan Supabase servisleri, veri boyutu ve bakım sorumlusu.

1. Cloud faturasında neyi satın aldığınızı bulun

Bir fatura yalnızca PostgreSQL işlemlerinden oluşmayabilir. Proje compute kaynakları, kullanım kalemleri ve ek seçenekler ayrı değerlendirilmelidir. Önce hangi projelerin gerçekten production olduğunu belirleyin. Deneme ortamının açık unutulması, müşteri başına ayrı proje oluşturulması ve gereksiz kapasite farklı optimizasyon fırsatlarıdır.

Planı düşürmeden önce kullanım raporunu ve gerekli özellikleri okuyun. Harcama sınırı her tür gideri aynı biçimde kapsamayabilir; sınırın varlığını toplam faturanın değişmeyeceği garantisi olarak yorumlamayın. Üretim ve test ortamlarını tek projede birleştirmenin veri güvenliği maliyetini de hesaba katın.

2. Veritabanı ile tüm Supabase yığınını ayırın

Sadece PostgreSQL kullanan bir uygulama ile Auth, Storage, Realtime ve Edge Functions kullanan uygulamanın taşıma kapsamı farklıdır. Bir VDS’ye PostgreSQL kurmak bu servislerin tamamını karşılamaz. Hangi SDK çağrısının hangi servise bağlı olduğunu çıkarmadan kaynak tahmini yapmayın. Özellikle küçük bir sunucunun tüm yığını yeterli performansla çalıştıracağını varsaymak gerçek ölçümün yerini tutmaz.

3. Operasyon görevlerini bütçeye yazın

Self-host ortamında güncelleme, güvenlik, izleme, kapasite ve kurtarma planı ekip tarafından işletilir. Görevleri bir kişinin gönüllü olarak halledeceği varsayımıyla sıfır maliyet yazmayın. Hangi işi kimin yapacağı, ne kadar süreceği ve izin döneminde kimin devralacağı belli olmalıdır. İlk kurulumun kolay görünmesi, ikinci ayın bakımının da ücretsiz olacağı anlamına gelmez.

• Veritabanı ve dosyalar için ayrı yedek/kurtarma kapsamı belirleyin.
• Sürüm güncellemesini staging ortamında ve geri dönüş planıyla deneyin.
• Disk, bağlantı ve hata alarmlarını bir sorumluya yönlendirin.
• Yedeklerin aynı disk veya aynı sunucu arızasına bağlı olmadığını kontrol edin.

4. Varsayımsal bir toplam maliyet hesabı

Aşağıdaki örnek tamamen sizin gireceğiniz gider mantığını açıklamak içindir. Uygulama Cloud’un planlanan Developer paketi 349 TL/ay ise bunun üzerine 100 TL ek hizmet ve 200 TL bakım yazıldığında aylık bütçe 649 TL olur. Mevcut bütçeniz 1.000 TL ise aradaki fark 351 TL’dir. Bunlar Supabase fiyatları veya gerçek ölçülmüş tasarruf değildir. Daha düşük mevcut faturada yeni bütçe daha pahalı çıkabilir.

Yeni aylık bütçe = kaynak + ek hizmetler + bakım
Geçiş gideri = veri taşıma + kod uyarlama + test + ekip zamanı

5. Güvenlik ve geri dönüşü denemeye dahil edin

RLS politikalarını ve kullanıcılar arası erişimi yeni ortamda test edin. Yetkili sunucu anahtarlarını mobil pakete koymayın. Veritabanı rolü değişirse aynı SQL’in yetki davranışı da değişebilir. Dosyalar, kullanıcı kimlikleri ve veri birlikte taşınmadığında bağlantılar bozulabilir; sadece tablo sayısı eşleşmesini başarı kabul etmeyin. Pilot sırasında eski sistemi gerekli süre erişilebilir tutun.

6. Hangi durumda hangi yaklaşım uygun?

Cloud, küçük ekibin operasyon yükünü azaltmak istediği ve mevcut özelliklerin iş akışına uyduğu durumda güçlü bir seçenek olabilir. Self-hosting, bakım yapabilecek ekibiniz, ölçülmüş iş yükünüz ve açık bir sorumluluk planınız varsa değerlendirilebilir. Sadece SQL’e ihtiyaç duyuyorsanız bağımsız PostgreSQL ve kendi API’niz daha dar kapsamlı bir seçenek oluşturur. Kararı üç yaklaşımın aynı kabul kriterlerini nasıl karşıladığını belgeleyerek verin.