Firebase, Supabase ya da Özel: Uygulama Backend Seçimi

Hiçbiri "ucuz olan" değil, çünkü ikisi aynı şeyi faturalamıyor. Firestore doküman işlemi başına ücret alıyor; yani faturası ekranlarınızın nasıl okuduğunun bir fonksiyonu. Supabase bir makineyi ve diskini faturalıyor; yani faturası ne kadar veritabanı kiraladığınızın fonksiyonu. Bu tek fark, uygulama bütçelerini her özellik karşılaştırmasından daha fazla belirliyor ve neredeyse hiç kimse ikinci fatura gelmeden önce yazmıyor.

İkisini de müşteri işlerinde kullanıyoruz. Seçim yaparken baktığımız şey veritabanlarından çok, uygulamanın kimse bakmadığında ne yaptığı; bu rehber de bunu karar vermeden önce nasıl yanıtlayacağınızı anlatıyor.

Firestore gerçekte neyi sayıyor

Firestore'un yayımlanmış oranları küçük rakamlar; atlanmalarının sebebi de bu. Google Cloud'un fiyatlandırma sayfası Standard sürümü, proje başına bir veritabanı için günlük 50.000 okuma, 20.000 yazma ve 20.000 silmelik ücretsiz kotanın üstünde 100.000 doküman okuma için 0,03 dolar, 100.000 yazma için 0,09 dolar olarak listeliyor.

Grafikteki oran, fiyatlardan daha önemli. Bir yazma, bir okumanın üç katı; bu da doküman deposunun standart tavsiyesini sessizce cezalandırıyor. Size okuma için denormalize etmeniz söyleniyor — yazarın adını her gönderiye kopyala, sayaç tut, kaydı ihtiyaç duyan her görünüme dağıt. Bu kopyaların her biri bir yazma, yani faturanın pahalı tarafı; ve yukarıda yapılan tek bir düzenleme aşağıda çok sayıda yazmaya dönüşüyor.

Bir de satın aldığınızı bilmediğiniz okumalar var. Google'ın kendi fiyatlandırma dokümantasyonu şunların her birini yazıyor:

• Sonuç döndürmese bile her sorgu için en az bir doküman okuma. Her tuş vuruşunda sorgu atan boş bir arama kutusu, sonuç bulan bir arama gibi faturalanıyor.
• exists(), get() ya da getAfter() çağıran Security Rules kuralları ek okuma olarak ücretlendiriliyor — üstelik neyi korudukları başlı başına bir beyan yükümlülüğü. Kullanıcının ekip üyesi olup olmadığını denetleyen kural, koruduğu her istekte ekip dokümanını okuyor.
• Gerçek zamanlı dinleyici, sonuç kümesindeki bir doküman her eklendiğinde ya da güncellendiğinde bir okuma yazıyor. Canlı güncellenen bir liste bir kez değil, ekranda kaldığı sürece her değişiklikte faturalanıyor.
• Toplama sorguları okunan indeks kaydı başına ücretlendiriliyor. 1.000 indeks kaydına kadar dokunan bir count() tek okuma; 1.500 kayıt iki okuma.

Bunların hiçbiri gizli değil — fiyatlandırma sayfasında, sırasıyla duruyor. Sadece kimsenin tahmin yaparken kullandığı şey değil; çünkü tahminler satır sayısından kuruluyor ve Firestore satır için ücret almıyor.

Var olmayan tavan

Ertelenen maliyet kontrolü, bunun bir tahmin sorunu olmaktan çıkıp riske dönüştüğü yer. Kullandıkça öde planında Firestore harcamasına tavan koymanın desteklenen bir yolu yok.

Google Cloud'un bütçe dokümantasyonu açık: yalnızca uyarı veren bir bütçe "Google Cloud ya da Google Maps Platform kullanımını veya harcamasını otomatik olarak sınırlamıyor". Servisleri gerçekten duraklatan daha yeni bir mekanizma var — harcama tavanı bütçeleri — ama önizleme aşamasında, uygulanmasının anlık olmadığı belgeleniyor ve uygun servisler Gemini API, Gemini Enterprise Agent Platform, Cloud Run ve Cloud Run functions. Firestore o listede değil.

Yani Eylül 2026 itibarıyla pratik durum şu: kontrolden çıkmış bir dinleyici, arka plan görevindeki bir yeniden deneme döngüsü ya da gerçekten başarılı geçen bir lansman haftası, varlığından bir uyarıyla haberdar olduğunuz bir fatura üretiyor. Çoğu uygulama için bu, tavanı düşük ve kabul edilebilir bir risk. Azami tutarı bilmek zorunda olan bir müşteri içinse diskalifiye edici; ve bunu bir olay sırasında keşfetmektense yüksek sesle söylemek gerekiyor.

Supabase bunun yerine neyi faturalıyor

Supabase işlemi değil kaynağı ölçüyor. Fiyatlandırma sayfasından:

Pro ve Team planları ayda 10 dolarlık işlem gücü kredisi içeriyor; bunun üstündeki işlem gücü ayrıca faturalanıyor. Sonuç, Firestore'un ayna görüntüsü: sorgu sayınız neredeyse bedava, boşta geçen zamanınız değil. Yirmi sorgu çalıştıran bir ekran, iki sorgu çalıştıranla aynı tutuyor — ta ki veritabanı daha büyük bir makineye ihtiyaç duyana kadar. Yüz kullanıcılı bir uygulama, kimse açmasa da veriyi tutacak boyutta bir makinenin parasını ödüyor.

Bir operasyonel ayrıntı dipnot değil kararın parçası olmalı. Supabase, ücretsiz projelerin bir haftalık hareketsizlikten sonra duraklatıldığını belirtiyor. Bu bir prototip için sorun değil, gerçek kullanıcısı olan hiçbir şey için doğru değil; çünkü sakin geçen bir hafta backend'inizi kapatıyor. Uygulama yayındaysa Pro'dasınız demektir; en baştan öyle fiyatlayın.

Uygulamanız hangisi

İkisini ayıran soru hangi veriyi sakladığınız değil. Kullanıcının dikkatinin her saniyesinde uygulamanızın ne yaptığı.

Firestore, ekranları yüklendikten sonra çoğunlukla sabit kalan ve kullanımı ani yükselen uygulamalara uyuyor — rezervasyon akışı, ödeme, öbek öbek kullanılan bir iç araç, uzun boş dönemlerin hiçbir maliyeti olmaması gereken her şey. Günlük ücretsiz kotası küçük uygulamaları gerçekten karşılıyor ve hiç sunucu düşünmüyorsunuz. Bu gerçek bir avantaj; aksini iddia etmeyeceğiz.

Supabase; canlı görünümleri, akışları, panoları, sohbeti, ortak düzenlemeyi olan ya da arayüzü sürekli okuyan uygulamalara uyuyor. Ayrıca henüz aklınıza gelmemiş biçimlerde sorgulamak isteyeceğiniz ilişkisel verisi olan her ürüne uyuyor; çünkü doküman deposu üzerinde raporlama, bu projelerin genelde tökezlediği yer. Ekibiniz zaten SQL biliyorsa ikinci ay yalnızca dolar olarak değil saat olarak da çok daha ucuz.

Özel backend, iki model de oturmadığında doğru: ağır arka plan işlemleri, hâlihazırda kullandığınız sistemlerle entegrasyonlar, iki servisin de karşılamadığı veri yerleşimi kuralları ya da doküman deposunun zorlaştırdığı bir alan modeli. Bunları biz yapıyoruz ve dürüst takas şu: daha önce kiraladığınız operasyonu artık siz üstleniyorsunuz. Bunun bir projenin biçimini nasıl değiştirdiğini mobil uygulama geliştirme rehberimiz, rakamına ne yaptığını fiyat rehberimiz anlatıyor; nasıl kapsamlandırdığımızı ise hizmet sayfamız.

Nerede hayır diyoruz

Müşteri duymak istemese de koruduğumuz iki tutum.

Bir müşteriyi, harcamanın tavanlanamayacağını söylemeden Firestore'un kullandıkça öde planına koymayız. Genelde yine de doğru seçimdir; ama kimse söylemediyse asla adil bir seçim değildir.

İki servisin de ücretsiz planında bir üretim uygulaması yayına almayız. Supabase ücretsiz projeleri bir haftalık hareketsizlikten sonra duraklatıyor; Firestore'un ücretsiz kotası ise proje başına tek veritabanı ve kötü bir gün için hiç pay bırakmıyor. İkisi de geliştirmek için uygun. İkisi de müşteri beklerken üstünde durulacak yer değil.

Bir öğleden sonrada karar vermek

1. Bir ekran kaça mal oluyor? Yoğun bir ekranın yaptığı doküman okumalarını, güvenlik kuralı okumaları ve dinleyici güncellemeleri dâhil sayın; beklediğiniz oturum sayısıyla çarpın. Çıkan rakam sizi korkutuyorsa kaynak üzerinden fiyatlanan seçeneği istiyorsunuz.
2. Bir hafta kimse uygulamayı kullanmazsa ne olur? Firestore neredeyse hiçbir şey almaz. Supabase makinenin parasını alır, ücretsiz planda ise projeyi duraklatır.
3. Harcamada sabit bir tavana ihtiyacınız var mı? Varsa, Firestore'un kullandıkça öde planı bugün bunu veremiyor.
4. Bu veri üzerinde raporlama yapacak mısınız? Doküman deposu üzerinde ilişkisel raporlama, bekleyen bir yeniden yazımdır.
5. Ekipte kim var? SQL yaygın bir beceri. Firestore veri modellemesi ve Security Rules ise özel bir beceri; pahalı hataların yaşadığı yer de ikincisi.

Bu hesabı tek başınıza yapmak istemiyorsanız, uygulamanın ne yapması gerektiğini bize gönderin; iki faturayı da sizin gerçek ekranlarınıza karşı modelleyelim — cevabın "hiçbiri, backend yazmalısınız" olduğu durum dâhil.