Supabase mi Cloudflare mı? Küçük ürünlerde altyapı kararları

Bir altyapı faturası yükseldiğinde teknoloji değiştirmek çok cazip geliyor. Supabase pahalıysa Cloudflare'e geçelim. Cloudflare sınırlı gelirse başka bir servise bakalım. Bu refleksi ben de yaşadım; özellikle Ordovia'da backend trafiği büyüyüp Supabase maliyeti görünür hale geldiğinde.

Fakat birkaç ürün boyunca aynı soruyla tekrar karşılaşınca kararın fiyatlandırma tablosundan daha büyük olduğunu fark ettim. Çünkü backend seçimi yalnızca aylık fatura seçimi değil. Auth modelini, veri ilişkilerini, deployment yüzeyini, debugging biçimini, migration maliyetini ve gelecekteki değişiklik hızını da seçiyorsunuz.

Doğru soru “Supabase mi Cloudflare mı?” değil. “Bu ürün bugün hangi karmaşıklığı gerçekten taşımalı?”

Önce iki şeyi aynı kategoriye koymayalım

Supabase ile Cloudflare birebir aynı ürünler değil. Supabase; PostgreSQL, auth, storage, realtime ve API katmanını bir araya getiren opinionated bir backend platformu. Cloudflare ise Workers, D1, KV, R2, Queues, Pages ve edge network gibi daha parçalı altyapı bileşenleri sunuyor.

Dolayısıyla karar “aynı işi yapan iki servis” arasında seçim yapmak değil. Daha çok hazır backend platformu ile compose edilebilir edge altyapısı arasında karar vermek.

Supabase'in en büyük avantajı: sıkıcı şeyleri hızla çözmesi

Bağımsız ürün geliştirirken en pahalı kaynak genellikle sunucu değil, dikkattir. Auth sistemi, kullanıcı tablosu, RLS, migration, storage ve ilişkisel veri için haftalar harcamak istemiyorsanız Supabase ciddi kaldıraç sağlıyor.

Özellikle ürünün değer önerisi backend mühendisliği değilse, “sıkıcı ama gerekli” parçaların hazır olması önemlidir. Bookcrumb gibi bir üründe benim asıl test etmek istediğim şey insanların okuma sistemini kullanıp kullanmayacağıysa, ilk haftalarda auth altyapısını icat etmek kötü bir yatırım olabilir.

1const earlyStagePriority = [2  "problem validation",3  "usable product",4  "real feedback",5  "then infrastructure perfection",6];

Bu nedenle küçük bir ürün için Supabase'i seçmek teknik olarak “en saf” çözüm olmayabilir ama ürün açısından en ekonomik çözüm olabilir.

Cloudflare'in en büyük avantajı: zaten oradaysanız yüzeyi küçültmesi

Benim projelerimde Cloudflare zaten deployment, domain, edge ve çeşitli API ihtiyaçlarında sık kullanılan bir katman. Bu durumda Workers, R2 veya D1 kullanmak yalnızca fiyat meselesi değil; operasyonel yüzeyi tek yerde toplama imkânı da veriyor.

Örneğin küçük ve ilişkisel karmaşıklığı sınırlı bir üründe “frontend başka yerde, API başka yerde, dosya başka yerde, cache başka yerde” dağılımı yerine birkaç Cloudflare primitive'i yeterliyse sistem gerçekten sadeleşebilir.

Altyapı konsolidasyonu değerli; ama sadece gerçekten konsolide ediyorsa. Beş yeni primitive öğrenmek için bir servisten çıkmak sadeleşme değildir.

Fatura görünce migration yapmak neden kötü başlangıç olabilir?

Ordovia'da Supabase kullanımının yaklaşık 2,6 milyon aylık isteğe çıkması ve faturanın görünür hale gelmesi beni alternatifleri daha ciddi düşünmeye itti. Fakat sorunların bir kısmı servis fiyatından değil, uygulamanın backend ile konuşma biçiminden kaynaklanıyordu.

Polling fazla olabilir. Aynı veri birkaç context tarafından çekiliyor olabilir. Cache politikası tanımsız olabilir. Mutation sonrası gereksiz refetch zincirleri oluşmuş olabilir. Bunları düzeltmeden servis değiştirmek çoğu zaman aynı davranışı farklı fatura modeline taşımaktır.

1const migrationDecision = {2  badReason: "current bill feels annoying",3  betterReasons: [4    "architecture fits the new platform better",5    "operational surface becomes smaller",6    "measured cost difference is meaningful",7    "migration risk is acceptable",8  ],9};

PostgreSQL ilişkileri sizin için değerliyse Supabase çok güçlü kalıyor

Ürün görev, proje, not, kullanıcı, ilişki, geçmiş ve raporlama gibi birbirine bağlı domain'ler taşıyorsa PostgreSQL'in rahatlığı küçümsenmemeli. SQL, transaction, foreign key, view, function ve güçlü sorgu modelinin değeri ürün büyüdükçe artıyor.

Ordovia gibi çok sayıda domain'in birbirine bağlandığı bir üründe veri modelinin ilişkisel olması yalnızca teknik tercih değil, ürün modelinin kendisi. Böyle bir sistemi sırf daha ucuz göründüğü için farklı bir veri modeline zorlamak yeni karmaşıklık yaratabilir.

D1 ne zaman daha doğal geliyor?

D1 benim için özellikle küçük, operasyonu basit ve edge'e yakın ürünlerde daha doğal bir seçenek. Birkaç temel tablo, sınırlı ilişki, net API sınırı ve düşük operasyon ihtiyacı varsa güçlü bir aday olabilir.

Ama “SQL var, o zaman PostgreSQL'in yerine geçer” diye düşünmüyorum. Veritabanı seçerken yalnızca sorgu diline değil; transaction beklentilerine, migration stratejisine, tooling'e, veri hacmine, concurrency davranışına ve ekibin debugging becerisine de bakmak gerekiyor.

Auth kararı, veri tabanı kararından daha pahalı olabilir

Bir servisten diğerine geçiş konuşurken en kolay gözden kaçan şey auth. Supabase Auth kullanıyorsanız kullanıcı oturumu, refresh token davranışı, RLS politikaları ve kullanıcı kimliğine bağlı veri erişimi sistemin pek çok yerine yayılmış olabilir.

Bu durumda migration yalnızca tablo taşımak değildir. Kimlik modelini de yeniden kurarsınız. Üstelik auth sorunları doğrudan kullanıcı kaybına dönüşebildiği için burada hata toleransı düşüktür.

1type MigrationSurface =2  | "data"3  | "auth"4  | "storage"5  | "api"6  | "background_jobs"7  | "observability"8  | "deployment";

Ben küçük ürünlerde artık dört aşamalı karar veriyorum

1. Ürünün asıl riskini bul

Risk kullanıcıların ürünü istememesi mi? O zaman backend'i hızlı kur. Risk karmaşık veri bütünlüğü mü? O zaman veri katmanını daha erken ciddiye al. Risk yüksek trafik mi? Daha ilk günden traffic modelini düşün.

2. En az operasyonla doğrulama yap

İlk sürümde kendi auth servisimi, queue sistemimi ve admin panelimi yazmak bana ürün hakkında yeni bilgi kazandırmıyorsa bunları yazmam.

3. Gerçek kullanım verisini ölç

Request sayısı, storage, CPU, database load veya bandwidth hakkında gerçek veri geldikten sonra optimizasyon kararı anlamlı hale geliyor.

4. Migration'ı ancak ekonomik bir iş olarak gör

Migration'ın kendisi bedava değil. Kod değişir, test gerekir, production riski oluşur ve zihinsel enerji tüketilir. Aylık birkaç dolar kazanç için haftalarca platform değiştirmek bağımsız geliştirici için çoğu zaman kötü matematiktir.

Basit karar matrisi

En tehlikeli şey: altyapı değiştirmeyi ilerleme sanmak

Bağımsız geliştirirken yeni teknoloji denemek çok keyifli. Üründe cevaplanması gereken zor bir soru varken altyapı migration'ı daha somut ve kontrol edilebilir bir iş gibi hissedebiliyor. Bu yüzden bazen teknik çalışma, ürün belirsizliğinden kaçışa dönüşüyor.

Kullanıcının istemediği bir ürünü yüzde 40 daha ucuz altyapıyla çalıştırmak başarı değil.

Bugün kendime şu sınırı koyuyorum: yeni altyapı, kullanıcı değerini, operasyon sadeliğini veya ölçülmüş maliyeti anlamlı biçimde iyileştirmiyorsa değişiklik yapmıyorum.

Sonuç: platform değil, karar disiplini

Supabase'i seviyorum çünkü ürünün sıkıcı backend parçalarını hızlı çözebiliyor. Cloudflare'i seviyorum çünkü edge, deployment, storage ve compute ihtiyaçlarını güçlü bir operasyon katmanında toplayabiliyor. İkisinin de kötü kullanılabileceği alanlar var.

Bu yüzden artık “hangi servis daha iyi?” sorusuna tek cevap vermiyorum. Ürünün veri modeli, trafik biçimi, geliştirme aşaması, ekip kapasitesi ve mevcut altyapısı cevabı değiştiriyor.

1function chooseInfrastructure(product: Product) {2  return optimizeFor([3    product.validationSpeed,4    product.dataModel,5    product.operationalSimplicity,6    product.measuredCost,7    product.migrationRisk,8  ]);9}

Benim için iyi altyapı artık en yeni veya en ucuz altyapı değil. Ürünün önüne en az çıkan ve gerektiğinde büyüyebilen altyapı.