Firebase mi Supabase mi? Ucuz başlangıç, gecikme faturasını gizleyebilir

Yeni uygulamanız çevrimdışı belge eşitlemesine dayanıyorsa Cloud Firestore kullanan Firebase; ilişkili kayıtları sık sorguluyor ve veritabanını ileride taşıma olasılığını önemsiyorsanız Supabase daha uygun adaydır. Karar, ücretsiz planın varlığından çok uygulamanın hangi işlemleri çoğaltacağına bağlıdır. Burada Firebase tarafında Cloud Firestore karşılaştırılıyor; Firebase’in diğer veritabanları aynı veri modeline veya fiyatlandırmaya sahip değildir.

Ucuz başlangıcın sonradan bedel yaratabileceği iki ayrı yol var: büyüyen okuma, dosya ve mesaj trafiği hizmet giderini artırabilir; kullanıcıya görünen yavaş bir işlem ise fonksiyonun ve veritabanının yerleşimini yeniden düzenlemeyi gerektirebilir. Dolayısıyla fiyat tablosu ile gecikme ölçümü, uygulamanın gerçek iş akışı üzerinden birlikte değerlendirilmelidir. Tek bir geliştirici gözlemi bütün kurulumlar için hız hükmü vermez.

Fiyatı hangi sayaç büyütür?

Firebase fiyat tablosunda Cloud Firestore Standard sürümünün ücretsiz sınırları günlük 50 bin belge okuması ve 20 bin belge yazmasıdır; saklanan veri ile ağ çıkışı ayrıca ölçülür. Cloud Functions için çağrı, çalışma kaynakları ve dış ağ trafiği de ayrı kalemlerdir. Cloud Storage for Firebase tarafında depolama, indirme ve dosya işlemlerinin sınırları bucket türüne göre değişir; fiyat tablosu bu hizmetin kullanımını Blaze planında gösterir. Fotoğraf taşıyan bir ürünün hesabını yalnızca Firestore okumalarından çıkarmak bu yüzden eksik kalır.

Supabase fiyat tablosu ücretsiz planda sınırsız API isteğiyle birlikte proje başına 500 MB veritabanı, 1 GB dosya depolama, 5 GB çıkış trafiği, aylık 2 milyon Realtime mesajı ve 500 bin Edge Functions çağrısı gösterir; etkin olmayan ücretsiz projeler bir haftanın ardından duraklatılır. API isteğinin sınırsız olması, veritabanı alanının, bağlantı kapasitesinin veya veri aktarımının sınırsız olduğu anlamına gelmez. Sık çağrılan fakat küçük yanıt döndüren bir sorgu ile az çağrılan fakat büyük dosya ileten bir uç nokta, farklı sınırlara yaklaşır.

Bu tabloların birimleri doğrudan birbirine çevrilemez. Firestore’da sorgunun okuduğu belgeler önem taşırken Supabase’de API istek sayısı tek başına maliyeti açıklamaz; sorgunun döndürdüğü veri, depolama ve ayrılmış kaynaklar da hesaba girer. İki platformda da kimlik doğrulama, dosya teslimi ve sunucu fonksiyonları veritabanı işlemlerinden ayrı bir kullanım oluşturabilir. Ücretsiz kotanın geniş görünmesi, uygulamanın en hızlı büyüyen sayacını gözden kaçırmaya neden olabilir.

Üç uygulamada aynı iş, farklı kullanım kalemleri

Şu senaryolar koşulludur; belirtilen davranışlar için verilmiş bir fatura tahmini değildir. Her birinde okuma, yazma, depolama ve fonksiyon çağrısını ayrı ele almak, iki fiyat modelini aynı kullanıcı eylemi üzerinden karşılaştırmayı sağlar.

• Çevrimdışı not uygulaması: Notların açılması ve yeniden eşitlenmesi Firestore’da belge okumaları, düzenlemeler belge yazmaları doğurur. Görsel ekleri ayrıca saklanır ve indirilir; bildirim ya da dönüştürme işlemi sunucuda yürütülürse fonksiyon kullanımı eklenir. Supabase’de aynı ürünün sorgu yanıtları ve dosya trafiği ölçülür, fakat çevrimdışı kopya ile bağlantı geri geldiğinde eşitleme davranışını uygulama mimarisi içinde çözmek gerekir. Böyle bir üründe hazır eşitleme davranışının geliştirme emeğine etkisi de fiyat kadar önemlidir.
• Fotoğraflı ürün kataloğu: Liste ekranındaki kayıt okumaları ve satıcının güncellemeleri veritabanı yükünü oluşturur. Fotoğrafların birikmesi depolama alanını, aynı fotoğrafın tekrar tekrar açılması indirme trafiğini büyütür. Firestore belge işlemleri ile Cloud Storage kalemleri ayrı izlenir; Supabase’de sınırsız API isteği bulunsa da veritabanı alanı, Storage alanı ve çıkış trafiği sınırlıdır. Görsel işleme fonksiyonla yapılırsa çağrı ve çalışma kaynakları da hesaba katılır.
• Grup sohbeti: Mesajı kaydetmek bir iş, onu açık sohbeti izleyen kullanıcılara ulaştırmak başka bir iştir. Firestore dinleyicilerinde değişen belgelerin okunması; Supabase Realtime tarafında mesajlar ve eşzamanlı bağlantılar önem kazanır. Ekler dosya depolama ile indirmeye, bildirim veya moderasyon ise fonksiyon kullanımına yük bindirebilir. Bu nedenle yalnızca gönderilen mesaj sayısını karşılaştırmak, sürekli açık bir sohbetin kullanımını temsil etmez.

Veri modeli ve gerçek zamanlı kullanım geçiş işini belirler

Supabase’in ürün karşılaştırması Cloud Firestore’u koleksiyonlardaki belgelerle, Supabase’i yabancı anahtarlar ve SQL sorguları kullanabilen Postgres tablolarıyla tanımlar; Firestore’un çevrimdışı önbellekleme ve yeniden eşitleme davranışını da açıklar. Sipariş, ürün ve satıcı kayıtlarını birlikte sorgulayan bir uygulama için ilişkisel model elverişlidir. Az ilişkili ve cihazda çevrimdışı tutulacak kayıtlar içinse belge modeli geliştirmeyi sadeleştirebilir. Bu tercih, yalnızca sorgu sözdizimini değil, verinin uygulamada nasıl çoğaltılıp güncelleneceğini de belirler.

Postgres verisi başka bir Postgres ortamına taşınabilir; yine de Supabase’den ayrılmak yalnızca tabloları kopyalamak değildir. Kimlik doğrulama, dosyalar, erişim politikaları, abonelikler ve fonksiyonlar yeni ortamda yeniden kurulabilir. Firestore’dan ilişkisel şemaya geçişte ise belge içindeki verilerin tablolara ayrılması ve sorguların yeniden yazılması gerekebilir. Başlangıçta daha az şema tasarımı yapmak ile ileride daha çok dönüştürme işi üstlenmek arasındaki denge, veri ilişkilerinin ne kadar değişeceğine bağlıdır.

Gerçek zamanlı özelliklerde de iki ürünün «güncelleme gönderiyor» olması yeterli bir karşılaştırma değildir. Hangi değişikliğin kaç açık istemciye ulaşacağı, sohbet gibi sürekli bağlantı kullanan ürünlerde belirleyicidir. Firestore’da dinleyicinin gördüğü belge değişiklikleri okuma kullanımına bağlanırken Supabase tarafında Realtime mesajları ve bağlantı kapasitesi izlenir. İlgisiz değişiklikleri bütün kullanıcılara ileten bir tasarım, seçilen platformdan bağımsız olarak gereksiz trafik üretir.

Fonksiyon gecikmesinde bölge ve veritabanı yolu

Bir geliştiricinin yayımladığı ekleme isteği gözleminde Firebase Functions yanıtı bir saniyenin altında, Supabase Edge Functions yanıtı iki saniyenin oldukça üzerinde gerçekleşmiş. Paylaşım, işlev kodunu, bölgeleri ve veritabanına giden yolu eşitleyen kontrollü bir deney sunmuyor; geliştirici sık çağrılarda da belirgin iyileşme görmediğini yazıyor. Bu sonuç belirli kurulumların uçtan uca yanıtını anlatır, yalnızca soğuk başlangıç süresini ölçmez.

Supabase’in bölgesel çağrı açıklamasına göre Edge Functions varsayılan olarak isteği yapan kullanıcıya yakın bölgede çalışır; yoğun veritabanı veya depolama işlemlerinde fonksiyonu veritabanıyla aynı bölgeye almak daha iyi sonuç verebilir. Türkiye’deki kullanıcıya yakın bir fonksiyonun uzaktaki Postgres’e gidip dönmesi, kullanıcıya görünen toplam süreyi etkileyebilir. Fonksiyonun başladığı yer kadar sorgu sayısı ve veritabanının yeri de önemlidir.

Gecikmenin maliyeti bu noktada yalnızca fonksiyon çağrısının fiyatı değildir. Kritik bir yazma işlemi gereğinden uzun sürüyorsa bölgeyi değiştirmek, ek ağ geçişlerini kaldırmak veya işlemi yeniden tasarlamak geliştirme işi yaratır. Seyrek kullanılan bir işlevde ilk yanıt ile ısınmış örneğin yanıtı ayrı değerlendirilmelidir. Yayımlanmış tekil gözlem, bu işin her uygulamada gerekeceğini veya iki platform arasında sabit bir hız farkı bulunduğunu göstermez.

Seçim hangi yükte değişir?

Çevrimdışı mobil kullanım ürünün temel özelliğiyse ve kayıtlar belge yapısına uyuyorsa Cloud Firestore güçlü bir başlangıçtır; belge okumalarıyla dosya indirmelerinin büyüme hızını birlikte hesaba katmak gerekir. İlişkili veriye sık sorgu, SQL ve veritabanını taşıma esnekliği ağır basıyorsa Supabase daha güçlü adaydır; bu kez veritabanı boyutu, çıkış trafiği ve Realtime kullanımı görünür tutulmalıdır.

Kullanıcıya görünen kritik işlem bir fonksiyondan geçiyorsa kararın son parçası o işlemin veritabanına kadar izlediği yoldur. Aynı iş yükünde ilk çağrı ile sonraki çağrıların süresi ve seçilen bölgeler, ücretsiz kota kadar somut bir seçim ölçütü verir. Böylece düşük başlangıç bedelinin ileride hangi kullanım kalemine veya mimari değişikliğe dönüşebileceği anlaşılır.

Ayrıca okuyun:

• Şahıs işletmesi mi limited şirket mi? Ucuz başlangıç riski gizleyebilir
• Yeniden kullanılabilir roket ucuz olmayabilir; kritik eşik yılda 6–9 uçuş
• Asana mı monday.com mu? Ucuz koltuk, kurulum süresini gizleyebilir