Aylık maliyet eğrisi nasıl büyüyor?
Supabase'in fiyat merdiveni nettir: Free planda $0/ay (500MB DB, 5GB egress, 50k aylık aktif kullanıcı), Pro planı $25/ay'dan başlıyor ve büyüdükçe kademeli ek ücretlere geçiyor — 8GB disk sonrası GB başına $0,125, 250GB egress sonrası GB başına $0,09, 100k MAU sonrası kullanıcı başına $0,00325. Team planı $599/ay'dan başlıyor ve SOC2 + ISO 27001 + SSO + 14 gün backup gibi kurumsal gereksinimleri ekliyor. Ayrıca ayrı bir compute add-on var: 1GB RAM'lik Micro instance $10/ay'dan başlayıp 64 vCPU/256GB RAM'e kadar ölçekleniyor.
Self-hosted PostgreSQL tarafında "fiyat sayfası" diye bir şey yok, çünkü yazılımın kendisi PostgreSQL Lisansı altında ücretsiz. Sen bu satırı okurken maliyet zaten VPS/donanım faturana kaymış durumda — PostgreSQL.org resmi bir maliyet ya da TCO karşılaştırması yayınlamıyor (yalnız üçüncü taraf hosting linkleri var). Pratik sonuç: küçük ölçekte Supabase'in Free planı muhtemelen daha ucuz görünür, ama kullanıcı/veri arttıkça iki modelin eğrisi farklı yönlere gider — biri kademeli kullanım-bazlı fatura, diğeri sabit altyapı + senin zamanın.
Auth, Storage, Realtime'ı kendin kurmanın gerçek maliyeti
Supabase'in resmi self-hosting dokümanı bu noktada dürüst: kendi sunucunda barındırdığında sunucu provisioning, servis konfigürasyonu ve yönetimi, yüksek erişilebilirlik/ölçeklenebilirlik, yedekleme ve felaket kurtarma ile izlemenin tamamı senin sorumluluğuna geçiyor. Supabase'in kendi Docker Compose self-host stack'i Auth (GoTrue), Storage, Realtime ve PostgREST servislerini de içeriyor — yani bileşenleri sıfırdan yazmak zorunda değilsin, ama işletmek zorundasın. Aynı dokümana göre self-host'ta branching, gelişmiş metrikler, yönetilen backup/PITR, analytics/vector bucket'lar ve platform yönetim API'si mevcut değil.
Saf PostgreSQL'de ise "auth/storage/realtime" kavramı yok — bunlar Supabase'in DB üzerine eklediği katman. PostgreSQL çekirdeği yalnız veritabanı motoru sağlıyor; bu bir eksiklik değil, kapsam farkı. Eğer kendi sunucunda bu üç servisi Supabase'in açık kaynak bileşenleriyle kurarsan, veriyi ve altyapıyı kontrol edersin ama yönetilen platformun otomatik sağladığı SLA, izleme ve ölçekleme mekanizmalarından mahrum kalırsın — bunu bir ekip olarak üstlenip üstlenemeyeceğini dürüstçe değerlendirmen gerekir.
Yedekleme, PITR ve restore provası disiplini
Supabase'in yönetilen platformunda backup planına göre kademeli: Pro planı son 7 günün günlük yedeklerine erişebiliyor, Team planı 14 güne, Enterprise planı 30 güne kadar. Free planda otomatik backup yok — resmi doküman açıkça "Free tier projeleri Supabase CLI'nin db dump komutuyla düzenli export almalı ve off-site yedek tutmalı" diyor. Point-in-time recovery ayrı, saniye hassasiyetinde bir add-on olarak sunuluyor.
Self-hosted PostgreSQL'de PITR, çekirdeğin resmi bir özelliği — WAL arşivleme ve pg_basebackup ile kurulur, ama kurulumu ve işletilmesi tamamen sana ait. Önemli bir nüans: self-host Supabase'de de yönetilen backup/PITR **devre dışı** (madde 2'deki aynı doküman) — yani kontrolü kendine alırken restore provasını da kendine alıyorsun. Bu yazının verdict_hint'inin özeti tam burada somutlaşıyor: yedek almak kriter değil, geri dönebilmeyi düzenli test etmek kriter. Hangi seçeneği seçersen seç, restore provasını takvimlemeyen bir ekip için "yedek var" cümlesi anlamsız bir güvence.
Bağlantı havuzlama ve uzantı özgürlüğü
Supabase üç pooler modu sunuyor: serverless/edge fonksiyonlar için "Shared pooler, transaction mode"; yalnız IPv4 destekleyen araçlar için "Shared pooler, session mode"; ve ücretli planlarda veritabanıyla aynı makinede çalışan, daha düşük gecikmeli "Dedicated pooler". Bunun altındaki motor, açık kaynak Supavisor — self-host'ta da kullanılabilir. Saf PostgreSQL'de havuzlama çekirdekte yok; PgBouncer ya da Supavisor gibi ayrı bir araç kurup işletmen gerekiyor, resmi doküman bağlantı/kimlik doğrulama ayarlarını anlatır ama bir pooler önermez.
Uzantı tarafında tablo tersine dönüyor: kendi sunucunda superuser erişimin olduğu için istediğin uzantıyı (pgvector, PostGIS, pg_cron, ne istersen) derleyip kurabilirsin — tam özgürlük. Supabase'de "Database Extensions" kataloğu üzerinden platform tarafından küratörlü, izin verilen bir uzantı listesi açılıyor; CREATE EXTENSION çalışır ama OS-seviyesi serbestlik yok. Supabase'in güncel olarak tam desteklediği uzantı sayısı bu araştırmada doğrulanamadı — docs sayfası mevcut ama içerik bu turda tam çekilemedi, iddia olarak burada yer almıyor.
RLS ve güvenlik sorumluluğu kimde?
Supabase'de Row Level Security, platformun Data API modelinin merkezinde — resmi doküman "Data API... Row Level Security gerektirir" diyor, yani frontend'den doğrudan tabloya erişim RLS politikalarına bağlı çalışıyor. Bu seni doğru alışkanlığa zorluyor: her tabloda RLS açık olmalı, aksi halde Data API üzerinden veri sızıntısı riski doğar. Self-hosted saf PostgreSQL'de RLS, 9.5 sürümünden beri çekirdek bir özellik, ama platform seni buna zorlamıyor — "kim erişir" kararı tamamen senin uygulama kodunda, bir API katmanı yoksa bu disiplin de yok.
Genel güvenlik sorumluluğunda fark daha keskin: Supabase self-host dokümanı "güvenlik sertleştirme ve OS/servislerin güncel tutulması" maddesini açıkça kullanıcı sorumluluğuna yazıyor — yani self-host ettiğin an, yönetilen planın arkasındaki güvenlik ekibi de devre dışı kalıyor. Yönetilen Supabase'de bu iş platformun; kendi sunucunda bu iş senin, patch takviminden firewall kuralına kadar.
KVKK ve veri yerleşimi
Supabase 17 bölge sunuyor ve seçtiğin bölgede Postgres veritabanın, Auth servisin ve Storage objelerin kalıyor — bu kadarı net ve resmi. Ama bölge listesinde **Türkiye yok**; en yakın seçenekler ABD, AB ve Asya-Pasifik bölgeleri. Bu, KVKK'nın yurt dışına veri aktarımı rejimine girdiğin anlamına gelir. İyi haber: Supabase HIPAA uyumlu (BAA ile), ISO 27001 sertifikalı, GDPR için DPA sunuyor ve veriyi AES-256 (durağan) + TLS (aktarımda) ile şifreliyor — yani "yurt dışında ama belgeli" bir konum.
Kendi sunucunda, örneğin Türkiye'deki bir VPS'te self-host PostgreSQL çalıştırdığında veri fiziksel olarak seçtiğin sunucuda kalır — veri yerleşimi sorusuna en doğrudan cevap budur. Ama dikkat: PostgreSQL.org resmi bir KVKK/GDPR uyumluluk beyanı yayınlamıyor, çünkü topluluk vakfı ticari bir uyumluluk sertifikası sunmuyor. Yani self-host'ta "veri Türkiye'de" doğru ama "sertifikalı uyumluluk" ayrı bir iş — bunu sen (ya da sözleşme yaptığın hosting sağlayıcın) kanıtlamak zorundasın.
Migration akışı, çıkış kolaylığı ve operasyonel yük
Supabase'in altında gerçek PostgreSQL çalıştığı için pg_dump/pg_restore ile dışa taşıma her zaman mümkün; resmi "migrating within Supabase" rehberi proje-arası taşımayı Node.js script örneğiyle (auth/storage dahil) anlatıyor. Self-host Docker Compose stack'i tamamen açık kaynak (Apache-2.0) ve .env dosyasıyla konfigüre ediliyor — teorik vendor kilidi düşük. Saf self-hosted PostgreSQL'de ise "çıkış" kavramı zaten yok, zira zaten kendi altyapındasın.
Operasyonel yük tarafında Supabase yönetilen planda seni büyük ölçüde rahatlatıyor: Eylül 2026'da eklenen Health Check Advisors, PostgREST/Auth/Storage/Edge Functions hata oranlarını otomatik izliyor. Ama self-host Supabase için resmi doküman net: "community-supported" — SLA ya da resmi on-call yok. Saf self-hosted PostgreSQL'de patch takvimi PGDG'nin minor sürüm döngüsüne bağlı (en az 3 ayda bir), ama uygulanması ve izlenmesi tamamen sende. Kısacası: yönetilen Supabase operasyonel yükü platforma devrediyor, self-host (ister saf Postgres ister self-host Supabase) bu yükü sana bırakıyor — karşılığında da tam kontrolü sana veriyor.