Supabase vs Neon tartışması 2026 itibarıyla yönetilen Postgres pazarında en sık sorulan karşılaştırma haline geldi. Kısa cevap şu: Supabase, Postgres’in üzerine inşa edilmiş tam bir backend platformudur (Auth, Storage, Realtime, Edge Functions, otomatik REST/GraphQL API); Neon ise saf bir serverless Postgres hizmetidir, storage-compute ayrımı ve dal-kopyala (branching) özelliğiyle ön plana çıkar. Vanilla self-hosted PostgreSQL ise maksimum kontrol ister ve TCO’su 100 GB altı yüklerde yönetilen alternatiflerin 2-3 katı operasyonel maliyete çıkabilir. Bu yazı; üç seçeneğin mimari farkları, fiyat modeli, performans davranışı, ekosistem desteği ve hangi senaryoda hangi platformun rasyonel olduğunu somut rakamlarla karşılaştırıyor.
2025 Stack Overflow Developer Survey’e göre PostgreSQL %51.9 ile profesyonel geliştiriciler arasında en çok kullanılan veritabanı (MySQL %38.9, SQLite %35.3 önünde). Bu hakimiyet, üç platformun tamamının aynı SQL diyalektini ve uzantı ekosistemini paylaşmasıyla doğrudan ilişkili. Karar; veri modelinden çok operasyon modelinden çıkıyor.
Üç Platformun Mimari Konumlandırması
Self-hosted PostgreSQL, Supabase ve Neon aynı çekirdeği paylaşsa da işletim modeli birbirinden ciddi şekilde ayrışıyor. Self-hosted, EC2/Hetzner gibi sanal sunucularda postgres servisinin kurulup tüm yedek, replica, vacuum ve patch süreçlerinin operasyon ekibine ait olduğu klasik model. Supabase, Postgres üzerine PostgREST, GoTrue, Realtime, pg_graphql ve Storage servislerini birleştirip Firebase alternatifi olarak konumlanan açık kaynaklı bir BaaS. Neon ise storage-compute ayrışması ile farklılaşıyor: compute node’ları saniyeler içinde “scale-to-zero” yapabiliyor, depolama ise S3 üzerinde versiyonlu page-server mimarisinde duruyor.
| Boyut | Self-hosted PostgreSQL | Supabase | Neon |
|---|---|---|---|
| Konum | VPS / Bare-metal | Yönetilen BaaS (AWS bölgeleri) | Serverless yönetilen Postgres |
| Postgres sürümü (2026 Q1) | 13-17 (kullanıcı seçimi) | 15, 17 (proje başına) | 14, 15, 16, 17 |
| Auth / Storage / Realtime | Yok (kullanıcı kurar) | Dahil (GoTrue, S3-uyumlu Storage, WAL bazlı Realtime) | Yok (uygulama katmanında) |
| Branching (DB klonlama) | Manuel pg_dump | Preview branches (CLI) | Copy-on-write, < 5 sn |
| Scale-to-zero | Yok | Free planda 7 gün inaktivite sonrası pause | Native, 5 dk inaktivite sonrası |
| Açık kaynak | PostgreSQL License | Apache 2.0 (self-host edilebilir) | Apache 2.0 (control-plane kapalı) |
Bu üç model arasındaki seçim, yalnızca veritabanı tercihi değil; uygulama mimarisinin yatay servisleri hakkında bir karar. Eğer Auth/Storage/Realtime ihtiyacınız varsa Supabase tek pakette çözüyor. Eğer yükünüz spike’lı ve idle süresi uzunsa Neon’un serverless modeli mantıklı. Eğer veri rejimi (KVKK, GDPR, sektörel) on-prem zorluyorsa self-hosted kaçınılmaz.
Bu kategoride mimari kararın altyapıyı nasıl etkilediğini daha kapsamlı görmek için PostgreSQL performans optimizasyonu rehberini ve veri yönetişimi kataloğunu inceleyebilirsiniz.
Fiyatlandırma ve Toplam Sahip Olma Maliyeti
Yönetilen Postgres karşılaştırmalarının en yanıltıcı kısmı fiyatlandırma. Free tier rakamları reklamlarda iyi durur ama prod yükünde gerçek bedel; compute saati, storage GB-ay, egress GB ve backup retention kalemlerinin toplamından çıkar. Aşağıdaki tablo Ocak 2026 itibarıyla resmi vendor sayfalarındaki listelenmiş fiyatları gösteriyor; bölge ve kur farkları nedeniyle gerçek fatura ±%10 oynayabilir.
| Plan | Self-hosted (Hetzner CX31, 4 vCPU, 8 GB) | Supabase Pro | Neon Launch |
|---|---|---|---|
| Aylık taban ücret | ~$15 sunucu + ~$8 backup | $25 | $19 |
| Dahil compute | 4 vCPU sürekli | 1 vCPU, 1 GB RAM (shared) | 1 CU-saat dahil + ek $0.16/CU-saat |
| Dahil storage | 80 GB NVMe (sunucu dahili) | 8 GB, ek $0.125/GB-ay | 10 GB, ek $1.50/GB-ay |
| Egress | 20 TB dahil | 250 GB dahil, ek $0.09/GB | Sınırsız (2026 Q1 itibarıyla) |
| Backup retention | Kullanıcı belirler | 7 gün PITR (ek $100/ay ile 14 gün) | 7 gün (branching tabanlı) |
| Operasyonel saat / ay (tahmini) | 8-15 saat DevOps | 0-2 saat | 0-1 saat |
100 GB altı bir SaaS yükü için tipik bir hesaplamada self-hosted’un TCO’su, DevOps saatini saatlik $40 ile çarpınca aylık $400-600 bandına ulaşır. Supabase Pro tipik kullanım için $50-80, Neon Launch ise scale-to-zero sayesinde dev/test ortamlarda $25-40 mertebesinde kalır. Veri büyüdükçe denklem değişir: 1 TB üstü yüklerde Neon’un $1.50/GB-ay storage maliyeti agresif şekilde artar, Supabase’in $0.125/GB-ay’ı ise daha rekabetçidir.
- Avantaj (Self-hosted): Sabit, öngörülebilir maliyet; aylık $20-30 ile 4-8 vCPU kazanılır.
- Dezavantaj (Self-hosted): Patch, replica failover, monitoring kurulumu insan-saat kabarık.
- Avantaj (Supabase): Auth + Storage + DB tek faturada, kullanıcı yönetimi sıfırdan kurulmaz.
- Dezavantaj (Supabase): 1 GB shared RAM Pro planda dar; ağır JOIN’lerde Compute Add-on (+$60-110/ay) gerekiyor.
- Avantaj (Neon): Idle ortamlarda fatura sıfıra yakın; PR önizleme branch’leri ücretsiz.
- Dezavantaj (Neon): Cold start 500-2000 ms; “always-on” modunda fiyat avantajı kayboluyor.
Performans, Latency ve Throughput Davranışı
Üç platform da aynı PostgreSQL motorunu kullandığı için tek-sorgu latency aşağı yukarı eşit (yerel disk vs. ağ bağlı storage farkı hariç). Ayrışma; kaldırma-bırakma performansı, cold start, concurrent connection kapasitesi ve backup-restore süresi gibi operasyonel ölçütlerde ortaya çıkıyor. Aşağıdaki tablo OnGres “WHICH-PG” 2024 ve Benchmarksdb.io 2025 testlerinden derlenmiş tipik değerleri özetliyor.
| Metrik | Self-hosted (NVMe) | Supabase Pro | Neon Launch |
|---|---|---|---|
| p50 SELECT (PK lookup, in-cache) | 0.3-0.6 ms | 0.8-1.4 ms | 0.9-1.6 ms |
| p99 INSERT (single row, fsync on) | 2-4 ms | 5-9 ms | 6-12 ms |
| Pgbench TPS (50 client, scale 10) | ~9.500 TPS | ~4.200 TPS | ~3.100 TPS (auto-scale) |
| Cold start (idle → ready) | Yok (always-on) | Yok (always-on) | 0.5-2.0 sn |
| Max connections | Yapılandırılabilir (200-2000) | 60 direct + PgBouncer 200 | 10.000 (proxy üzerinden) |
| WAL replay restore (10 GB) | 3-5 dk | 5-8 dk | <1 dk (page-server kopyası) |
Mikrobenchmark’lar tek başına yanıltıcıdır. Gerçek uygulama yükünde Supabase’in REST/GraphQL katmanı (PostgREST) işlem başına ~3-6 ms ek latency getirir; uygulamanız raw SQL bağlantı kuruyorsa bu pay kalkar. Neon’un asıl gücü, analytics ve geliştirme branch’leri; üretim OLTP yüklerinde proxy ek hop’u (~1-3 ms) görünür. Self-hosted, NVMe ve doğru shared_buffers + effective_cache_size ayarıyla diğer ikisinin 2-3 katı TPS verir ama bu performansa ulaşmak için tuning bilgisi şart.
Bağlantı havuzlaması (connection pooling), serverless senaryolarda en kritik faktör. PgBouncer üç platformda da kullanılabilir; Supabase entegre sunar (Supavisor), Neon ise kendi proxy katmanını yönetir. Tipik bir Lambda/Edge fonksiyon yükünde Neon proxy 10.000+ eşzamanlı bağlantıyı 60 backend bağlantısına multiplex’leyebilir — bu, self-hosted’da manuel PgBouncer ile sağlanan davranışın native versiyonu.
Ekosistem, Uzantılar ve Veri Tipi Desteği
Postgres’in gücü uzantı ekosisteminden gelir; bu nedenle hangi platformun hangi CREATE EXTENSION komutunu kabul ettiği kararı doğrudan etkiler. PostgreSQL resmi contrib modülleri her üçünde de mevcut; iş üçüncü parti uzantılara gelince ayrışma başlıyor.
| Uzantı | Self-hosted | Supabase | Neon |
|---|---|---|---|
| pgvector (vektör arama) | Kurulabilir | Dahili, v0.7+ | Dahili, v0.7+ |
| PostGIS (geospatial) | Kurulabilir | Dahili | Dahili (3.4) |
| TimescaleDB | Kurulabilir | Dahili (apache2 sürüm) | Yok |
| pg_partman (partitioning) | Kurulabilir | Dahili | Yok |
| pg_cron | Kurulabilir | Dahili | Yok (Neon scheduled jobs ayrı) |
| pgaudit / pg_stat_statements | Kurulabilir | Dahili | pg_stat_statements var, pgaudit yok |
| Logical Replication (publication) | Tam | Tam | Tam (subscriber + publisher) |
pgvector üzerinden RAG ve embedding tabanlı mimariler kurmak isteyenler için her üç platform da elverişli; ancak hibrit (Postgres + ayrı vektör DB) senaryolarını değerlendirmek için vektör veritabanı karşılaştırma yazımız daha geniş bir manzara veriyor. Time-series odaklı yükler (IoT, finans tick verisi, observability) için Supabase’in TimescaleDB desteği avantaj sağlar; Neon bu konuda boşluk bırakıyor ve kullanıcıların BRIN index’ler veya manuel partitioning ile devam etmesi gerekiyor.
Geliştirici Deneyimi: Branching, Migration ve Local Dev
Modern uygulama geliştirme; her PR için izole bir veritabanı klonu, versiyonlu schema migration ve lokal-prod paritesi ister. Üç platform bu üç eksende farklı yaklaşımlara sahip.
- Self-hosted: Branching için
pg_dump | psqlveyapg_basebackup. Tipik 50 GB DB klonlaması 8-20 dakika sürer, disk maliyeti 1:1 çoğalır. - Supabase: CLI ile preview branches; her branch izole bir Postgres instance. GitHub entegrasyonu var, 2026 Q1 itibarıyla branch başına saatlik billing.
- Neon: Copy-on-write branching, 5 saniyenin altında. 100 GB’lık bir parent’tan oluşturulan branch’in disk maliyeti yalnızca delta sayfalar kadar. PR başına bir branch açıp merge sonrası silmek mainstream pattern.
Migration tarafında üçü de Prisma Migrate, Sqitch, golang-migrate veya Rails-style schema files ile uyumludur. Supabase ek olarak Supabase CLI içinde supabase migration new akışı sunar; Neon ise neonctl branches create --parent main --name pr-123 komutuyla migration test akışını ekleyebilir. Self-hosted’da bu süreçler %100 sizin elinizde ama sorumluluk da sizde.
Lokal geliştirme açısından Supabase, supabase start komutuyla Docker üzerinde tüm stack’i (DB + Auth + Storage + Studio) ayağa kaldırır — bu BaaS rakipsiz. Neon ise lokal olarak yalnızca standart PostgreSQL kullanmanızı önerir; Neon’a özgü branching/scale-to-zero davranışları lokal taklit edilemez. Self-hosted’da lokal ile prod aynı binary olduğu için parite mükemmeldir.
Auth, Storage, Realtime ve Edge Functions
Supabase’in “Postgres’ten fazlası” iddiası burada somutlaşıyor. Karşılaştırmayı doğrudan yapmak gerekiyor: Neon ve self-hosted, salt veritabanı katmanı; uygulama katmanı için NextAuth, Keycloak, MinIO, Pusher veya Ably gibi ek bileşenleri siz seçip yönetirsiniz.
| Servis | Self-hosted | Supabase | Neon |
|---|---|---|---|
| Auth (JWT, OAuth, MFA) | NextAuth/Keycloak ile entegre | GoTrue, 20+ provider, MFA dahil | Yok (uygulama tarafı) |
| Object Storage | MinIO, S3, R2 ayrı entegre | S3-uyumlu, RLS-bağlı erişim | Yok |
| Realtime (WebSocket) | Soketi, Pusher self-host vb. | WAL bazlı broadcast, RLS | Yok |
| Edge Functions | Yok (Cloudflare Workers ayrı) | Deno bazlı, 30+ bölge | Yok |
| Vector embeddings + RAG | pgvector + uygulama kodu | pgvector + Studio entegre | pgvector + uygulama kodu |
Bu nedenle Supabase, MVP ve “5 günde launch” senaryolarında tek favori konumunda. Neon, compute tarafını çözen ama Auth/Storage’ı uygulama mimarına bırakan modern bir Postgres’tir; tipik kullanıcısı Next.js + Vercel veya AWS Lambda ile Postgres’i lego gibi takıp çıkaran ekip. Self-hosted, regulasyon (özellikle KVKK ve sektör spesifik veri ikametgâhı) zorlayan senaryolarda hâlâ tek geçerli yol.
Mimari karar verirken veri akışı yönünü de düşünmek gerekiyor; özellikle event-driven mimarilerde Postgres’in CDC (change-data-capture) yeteneği stream processing katmanına nasıl beslendiği belirleyicidir. Logical replication üç platformda da çalışır; Supabase ve Neon, Debezium ile uyumludur.
Güvenlik, Uyumluluk ve Veri Egemenliği
Yönetilen platform seçiminde sıklıkla atlanan boyut: veri nerede duruyor, kim erişebiliyor, hangi sertifikasyona sahip? Supabase güvenlik dokümanına göre SOC 2 Type 2 ve HIPAA (Team plan ve üzeri) uyumluluğu mevcut; ISO 27001 ise 2025’te alındı. Neon, SOC 2 Type 2 ve HIPAA uyumlu, ISO 27001 ise 2024 Q4’te tamamlandı.
- KVKK / GDPR veri ikametgâhı: Supabase EU bölgeleri (Frankfurt, Dublin, Paris, Stockholm) sunuyor; Neon EU-Central-1 (Frankfurt) ve EU-West-2 sunar. Self-hosted için sunucu yeri tamamen sizin elinizde.
- Row Level Security (RLS): Üç platformda da PostgreSQL native RLS aktif. Supabase, JWT iddialarını
auth.uid()içine map’leyerek RLS yazımını basitleştirir. - Encryption at rest: Üçü de AES-256. Self-hosted’da sorumluluk size, Supabase/Neon’da default açık.
- Audit logging: Self-hosted ve Supabase
pgauditsunar; Neon henüz pgaudit desteği eklemedi (yol haritasında). - Veri sızıntısı bildirimi: Yönetilen platformlar olay yönetimini üstlenir; self-hosted’da KVKK 72 saat ihbar sorumluluğu sizdedir.
Yapay zekâ destekli içerik üretimi ve danışmanlık tarafında Ömer Önal, Türkiye’de regulasyon-uyumlu yönetilen Postgres mimarilerinde sıklıkla “Supabase EU bölgesi + self-hosted PgBouncer + ayrı S3 storage” hibrit modelini öneriyor. Çünkü tek bir vendor’a tam bağımlılık, KVKK denetimlerinde ek belge yükü getirebiliyor.
Ölçeklendirme: Read Replica, Sharding ve Multi-Region
Aylık 100 milyon istek ve üzeri yükte hangi platformun sınırı zorlanıyor? Bu sorunun cevabı 2026’da hala devam eden Postgres ölçeklendirme tartışmasının özü.
| Ölçek Eksenı | Self-hosted | Supabase | Neon |
|---|---|---|---|
| Read replica desteği | Streaming replication, sınırsız | Var (Pro+ planlarda, ek $25-100/replica) | Read replica branches, oto-skale |
| Multi-region read | Manuel logical replication | Var, premium plan | Pre-GA |
| Sharding | Citus, pg_shard, manuel | Yok (vertical scale) | Yok (vertical scale) |
| Max DB boyutu (tek instance) | Donanıma bağlı (10+ TB pratik) | 500 GB (üstü teknik destek ile) | 10 TB |
| Vertical scale max | Bare-metal (96+ vCPU) | 16 vCPU, 64 GB RAM | 16 vCPU, 56 GB RAM (CU) |
10 TB ve üzeri OLTP yüklerinde üç platform da yetersiz kalmaya başlar; bu noktada analitik bir warehouse’a CDC beslemek veya data lakehouse mimarisine geçmek gündeme gelir. Sharding ihtiyacı olan B2C yükler için Citus uzantısı self-hosted’da hâlâ en olgun seçenek; Supabase ve Neon yatay sharding’i şu anda native sunmuyor.
Multi-region read latency, küresel kullanıcı tabanı olan uygulamalar için kritik. Supabase 2025’te global read replica’yı GA yaptı; Neon 2026 Q1 itibarıyla pre-GA aşamasında. Self-hosted için pglogical ve BDR gibi opsiyonlar var ama operasyonel olarak ağır.
Hangi Senaryoda Hangi Platform: Karar Çerçevesi
Soyut karşılaştırma yetmez; somut karar matrisine ihtiyaç var. Aşağıdaki 5’li liste; en sık karşılaşılan senaryolarda hangi platformun rasyonel olduğunu özetliyor.
- MVP / Startup (0-10K kullanıcı): Supabase. Auth + DB + Storage tek pakette, 5 günde launch mümkün. Ne zaman seç: ekip 1-3 kişi, mobile veya web frontend, hızlı iterasyon gerekiyor. Ne zaman seçme: 1 TB+ veri öngörüsü varsa storage fiyatı ısırır.
- Serverless Next.js / Vercel: Neon. Edge function başına saniye altı cold start, branching ile PR önizleme. Ne zaman seç: idle süresi uzun, geliştirme ortamı sayısı çok. Ne zaman seçme: TimescaleDB veya pg_cron şart ise.
- Veri yoğun analytics + OLTP hibrit: Self-hosted + Citus. Tam kontrol, sharding, custom uzantı. Ne zaman seç: 1-10 TB OLTP, sektör regulasyonu, dedike DBA var. Ne zaman seçme: küçük ekip, DevOps zayıf.
- Realtime collaboration (Figma-vari): Supabase. WAL bazlı broadcast + RLS + presence. Ne zaman seç: WebSocket trafiği yoğun, kullanıcı oturumu kalıcı. Ne zaman seçme: 100K+ eşzamanlı bağlantı gerekiyorsa kendi Realtime katmanını kur.
- Düzenleyici (BDDK, SPK, KVKK sıkı sektörler): Self-hosted, EU bölgesi. Veri çıkışı tam kontrol, audit log tam. Ne zaman seç: denetim sıklığı yüksek. Ne zaman seçme: ekipte Postgres deneyimi 1 yıldan az.
Bu çerçeveyi tamamlayıcı olarak, veri mimarisinin nasıl federasyon’a evrildiğini gösteren data mesh yazısı ve büyük ölçek pipeline’larını ele alan big data işleme rehberi, Postgres seçiminin ekosistemdeki yerini netleştirir.
Sıkça Sorulan Sorular (SSS)
Supabase ile Neon arasındaki en temel fark nedir?
Supabase, Postgres’in üzerine Auth, Storage, Realtime, Edge Functions ekleyen tam bir BaaS; Neon ise saf serverless Postgres. Supabase, “Firebase alternatifi” olarak konumlanırken Neon, “AWS RDS’in modern serverless versiyonu” gibi davranır. Auth/Storage ihtiyacı varsa Supabase tek paket; salt yönetilen DB istiyorsanız Neon daha yalın.
Self-hosted PostgreSQL ne zaman Supabase veya Neon’a tercih edilir?
Veri ikametgâhının özel olarak kontrol edilmesi gereken (KVKK ağır sektör, askeri, BDDK), 5+ TB OLTP yükü olan veya Citus tarzı sharding gerektiren senaryolarda self-hosted hâlâ tek geçerli yoldur. Ayrıca DevOps ekibi olgun ve hawk-eye monitoring kuracaksa, sabit aylık maliyet açısından da kazançlıdır.
Neon’un scale-to-zero özelliği prod’da güvenli midir?
Geliştirme, staging, demo ortamlarında ideal. Prod’da kullanıcı talebine kullanıcı talebinin geldiği ilk 0.5-2.0 sn cold start olduğu için, p99 latency hedefiniz 1 sn altıysa “always-on” mod (ek ücretli) önerilir. Tipik B2B SaaS için scale-to-zero üretimde de uygulanabilir; B2C kullanıcı odaklı flow’larda dikkat gerektirir.
Supabase fiyatı projemde nasıl tahmin edebilirim?
Pro plan $25 taban + her ek GB storage $0.125 + her ek GB egress $0.09 + active user’a bağlı Auth maliyeti. 50K MAU, 100 GB DB, 500 GB ay egress için tipik fatura $80-120 bandında. Realtime ve Edge Functions kullanım bazlı ek geliyor; resmi pricing kalkulatörü en doğru sonucu verir.
Üç platformdan birinden diğerine geçiş ne kadar zor?
Postgres ortak diyalekt olduğu için pg_dump + pg_restore ile şema ve veri taşınır; tipik 100 GB DB için 30-90 dk. Asıl maliyet uygulama katmanında: Supabase’den ayrılıyorsanız Auth/Storage’ı yeniden kurmanız gerekir. Neon’dan self-hosted’a geçiş en kolayı, çünkü Neon zaten standart Postgres protokolü konuşur.
Sonuç
2026’da yönetilen Postgres seçimi, “hangi DB?” sorusundan çok “uygulama mimarinizin yatay servislerini hangi seviyede outsource ediyorsunuz?” sorusuna dönüştü. Supabase, Auth/Storage/Realtime gerektiren full-stack ekipler için açık ara en hızlı yol; özellikle MVP ve startup aşamasında diğer iki seçeneğin önüne geçiyor. Neon, serverless ve branching odaklı modern geliştirme akışları için biçilmiş kaftan; özellikle Vercel/Cloudflare ekosistemindeki ekipler için cold start dezavantajını dev ortamlarda avantaja çeviriyor. Self-hosted PostgreSQL ise hâlâ regulasyon, ölçek ve özel uzantı ihtiyacı olan senaryolarda tek doğru cevap.
Karar verirken üç boyutu birlikte düşünmek gerekiyor: (1) veri büyüklüğü ve büyüme eğrisi, (2) ekibinizin DevOps kapasitesi, (3) regulasyon ve uyumluluk beklentileri. 100 GB altı, 1-3 kişilik ekip, EU veri ikametgâhı yeterli ise Supabase EU bölgesi; aynı parametrelerde TimescaleDB veya pg_cron gerekmiyorsa Neon Launch; 1+ TB OLTP veya BDDK düzeyinde audit gerekiyorsa self-hosted + dedike DBA.
Her üç seçeneğin doğru senaryoda ışıltısı farklı. Şirket içi POC kurarken hibrit mimari kararı vermek ve “hangi servis nerede çalışsın?” matrisini netleştirmek için iletişim formundan Postgres mimarisi danışmanlığı talep edebilirsiniz; ekibinizin yüküne ve ekibinizin operasyonel olgunluğuna göre 1-2 saatlik mimari atölyede karar matrisi netleşir.
Ömer ÖNAL
Mayıs 16, 2026Veri mühendisliği projelerinde sıkça gördüğüm darboğaz: pipeline mimarisine yatırım yapmadan önce veri kalitesi metriklerinin baseline’ı yok. Great Expectations veya benzer bir validation katmanı ilk faza dahil edilirse, sonraki pipeline değişiklikleri tahmin edilebilir hale geliyor. Yorumlarınız ne yönde?