Supabase vs Neon Karşılaştırması

Postgres'in etrafında tam bir backend: auth, storage, realtime, functions

VS
Neon

Saf serverless Postgres: copy-on-write branching, artık Databricks'in motoru

19 dk okumaBackend

Hızlı Karar

"Hangisi daha iyi" değil, "bana ne lazım" sorusu. Auth+Storage+Realtime+Functions'ı olgun halde tek platformdan istiyorsan Supabase'i seç. Yalnız Postgres + branch-per-PR + compute-saniye faturalama istiyorsan Neon daha güçlü — Auth/Storage/Functions 17 Eylül 2026'da GA oldu ama saha geçmişi çok daha kısa. Prisma/Drizzle ikisinde de çalışır; pooler transaction-mode'unda prepared statement uyumsuzluğu ek ayar ister. ORM seçimi kararı belirlemez.

SupabaseNeon
Tam sonucu oku

Puan Karşılaştırması

Grafik yükleniyor...

Detaylı Puanlama

Detaylı Puanlama: Supabase ve Neon — kategori bazında 10 üzerinden puanlar
KategoriSupabaseNeon
Performans
8/10
8/10
Öğrenme Kolaylığı
8/10
7/10
Ekosistem
9/10
6/10
Topluluk
9/10
6/10
İş Pazarı
6/10
6/10
Gelecek
8/10
7/10

Artıları & Eksileri

Supabase

Artıları

  • Auth, Storage, Realtime ve Edge Functions tek projede hazır ve GA — ayrı servis entegre etmene gerek yok
  • Row Level Security (RLS) ile veritabanı seviyesinde yetkilendirme, client'tan doğrudan güvenli sorgu
  • Docker Compose ile gerçek self-host seçeneği, telemetri yok
  • Geniş bölge kapsamı (17 spesifik AWS bölgesi + 3 bölge grubu)
  • Passkeys dahil olgun Auth (2026-06 beta), geniş social/SSO sağlayıcı listesi
  • Pipelines ile Postgres→BigQuery CDC (2026-07-21 public alpha) ve Unified Logs (2026-07-16 open beta)
  • Açık kaynak (Apache-2.0), ≈110,6 bin GitHub yıldızı (23 Eyl 2026) ile büyük topluluk
  • Bağımsız şirket — 2026-06'da $500M Series F, roadmap dış platform stratejisine bağlı değil

Eksileri

  • Self-host sürümünde branching, managed backup+PITR, platform API gibi yönetilen-platform özellikleri yok
  • Free plan projeleri 1 hafta inaktivite sonrası pause olur — manuel/otomatik unpause gerekir, Neon'un saniyeler içindeki otomatik uyanmasına göre daha yavaş bir model
  • Branch'ler migration-tabanlı ve seed data ile başlar — üretim verisinin gerçek kopyası değil (Neon'un storage-seviyesi copy-on-write klonuna göre daha sığ)
  • Sabit tier fiyatlandırma (Pro $25/ay, Team $599/ay) küçük projelerde Neon'un ince taneli compute-saniye modeline göre daha az esnek olabilir
  • Prisma/Drizzle ile pooler transaction-mode'da prepared statement uyumsuzluğu bilinen bir sorun (workaround gerekir)

En Uygun

Auth + Storage + Realtime + Edge Functions'ı tek platformdan hazır isteyen ürün ekipleriRLS ile client-taraflı güvenli sorgulama tasarlayan mobil/web uygulamalarıSelf-host gereksinimi olan, tam kontrolü elde tutmak isteyen kurumsal ekiplerHızlı MVP'den ölçekli SaaS'a tek platformda büyüyen ürünlerVendor lock-in riskini büyük bir bulut platformuna (Databricks gibi) değil, bağımsız bir şirkete vermek isteyenler

Neon

Artıları

  • Branch = storage-seviyesi tam copy-on-write klon, prod veriyle — Vercel entegrasyonuyla her preview deploy'da otomatik açılır
  • Scale-to-zero: 5 dk inaktivite sonrası askıya alma, yeniden aktivasyon birkaç yüz milisaniyede
  • PgBouncer tabanlı bağlantı havuzu 10.000 eşzamanlı bağlantıya kadar ölçekleniyor — serverless/edge fonksiyonlar için tasarlanmış
  • Neon backend GA (17 Eyl 2026): tek `neon.ts` dosyasından Auth+Storage+Functions+AI Gateway dahil tüm backend branch'lenebiliyor
  • İnce taneli compute-saniye fiyatlandırma — küçük/düzensiz trafikli projelerde sabit tier'a göre daha ucuz olabilir
  • Açık kaynak (Apache-2.0), tam Postgres uyumluluğu, proprietary lock-in iddiası yok

Eksileri

  • Auth (Managed Better Auth), Object Storage ve Functions 17 Eylül 2026'da GA oldu — yani Supabase'in yıllardır production'da olgunlaşmış eşdeğerlerine göre saha geçmişleri çok daha kısa
  • Object Storage yalnız 4 AWS bölgesinde (Ohio, N. Virginia, Frankfurt, Singapore) — Supabase'in storage/realtime'ının çalıştığı geniş bölge yelpazesine göre dar
  • Proje oluşturulduktan sonra bölge değiştirilemez, taşımak için yeni proje + migrasyon gerekir
  • 14 Mayıs 2025'te Databricks tarafından satın alındı — ürün artık 'Lakebase Postgres, by Databricks' konumlanıyor, bağımsız roadmap yerine büyük bir platform şirketinin Lakehouse stratejisine bağımlı
  • Resmi, ayrı bir self-host Docker rehberi bu araştırmada bulunamadı — self-host çıkış yolu Supabase kadar net belgelenmemiş

En Uygun

Branch-per-PR CI/CD akışı kuran ve preview ortamlarında gerçek production verisiyle çalışmak isteyen ekiplerYalnızca Postgres isteyen, kendi auth/storage/realtime katmanını seçmek isteyen mimarilerServerless/edge runtime'lardan (Vercel Edge, Cloudflare Workers) HTTP tabanlı sürücüyle bağlanan uygulamalarDüzensiz/düşük trafikli projelerde compute-saniye bazlı faturalamadan fayda görmek isteyenlerDatabricks/Lakehouse ekosistemiyle zaten entegre olan kurumsal veri ekipleri

Kod Karşılaştırması

Supabase
// Supabase — RLS korumalı sorgu + Storage upload (TypeScript)
import { createClient } from '@supabase/supabase-js'

const supabase = createClient(
  process.env.SUPABASE_URL!,
  process.env.SUPABASE_ANON_KEY!
)

// RLS politikası "select_own_posts" ile korunan tablo
const { data: posts, error } = await supabase
  .from('posts')
  .select('id, title, created_at')
  .eq('author_id', userId)
  .order('created_at', { ascending: false })
  .limit(20)

if (error) throw error

// Aynı proje içinde Storage — imzalı upload URL
const { data: uploadUrl } = await supabase.storage
  .from('avatars')
  .createSignedUploadUrl(`${userId}/profile.png`)

// Realtime — Postgres Changes ile canlı dinleme
supabase
  .channel('posts-changes')
  .on(
    'postgres_changes',
    { event: 'INSERT', schema: 'public', table: 'posts' },
    (payload) => console.log('Yeni post:', payload.new)
  )
  .subscribe()
Neon
# Neon — CLI + serverless driver (bash + TypeScript)

# --- bash: PR başına branch aç/sil (CI adımı) ---
# 1) Ana branch'ten anlık copy-on-write klon oluştur
neon branches create \
  --project-id $NEON_PROJECT_ID \
  --name "preview/pr-${PR_NUMBER}" \
  --parent main

# 2) Bu branch'in pooled connection string'ini al
neon connection-string "preview/pr-${PR_NUMBER}" --pooled

# 3) PR kapanınca branch'i sil (temiz preview ortamı)
neon branches delete "preview/pr-${PR_NUMBER}" --project-id $NEON_PROJECT_ID

// --- TypeScript: serverless ortamda (Vercel Edge/Cloudflare Workers) HTTP tabanlı sürücü ---
import { neon } from '@neondatabase/serverless'

const sql = neon(process.env.DATABASE_URL!) // pooled, PgBouncer arkasında

const rows = await sql`
  SELECT id, title, created_at
  FROM posts
  WHERE author_id = ${userId}
  ORDER BY created_at DESC
  LIMIT 20
`

Sonuç

"Hangisi daha iyi" değil, "bana ne lazım" sorusu. Auth+Storage+Realtime+Functions'ı olgun halde tek platformdan istiyorsan Supabase'i seç. Yalnız Postgres + branch-per-PR + compute-saniye faturalama istiyorsan Neon daha güçlü — Auth/Storage/Functions 17 Eylül 2026'da GA oldu ama saha geçmişi çok daha kısa. Prisma/Drizzle ikisinde de çalışır; pooler transaction-mode'unda prepared statement uyumsuzluğu ek ayar ister. ORM seçimi kararı belirlemez.

Ücretsiz Danışmanlık Al
SSS

Sıkça Sorulan Sorular

Kısa cevap: ihtiyacına bağlı. Saf, dallanabilir serverless Postgres + minimum vendor lock-in istiyorsan Neon; auth, storage, realtime ve edge functions'ı tek platformdan hazır istiyorsan Supabase. Karar aslında 'hangisi popüler' değil, 'bana platform mu yoksa sadece veritabanı mı lazım' sorusuna indirgeniyor.

Giriş

Postgres seçtin, iyi de şimdi soru şu: "bana hazır bir backend mi lazım, yoksa ölçeklenen bir veritabanı mı?" Supabase ve Neon ikisi de Postgres üzerine kurulu, açık kaynak, 2026'da hızla genişliyor — ama farklı yönlerde. Supabase 2020'den beri Firebase'e açık kaynak alternatif: Postgres'in üzerine Auth, Storage, Realtime ve Edge Functions'ı RLS ile entegre ekliyor. 2026-06'daki $500M Series F'le bağımsız kalıyor. Neon ise storage-compute ayrımıyla saniyeler içinde branch açan, kullanılmadığında sıfıra inen "saf" serverless Postgres olarak başladı. 14 Mayıs 2025'te Databricks tarafından satın alındı; 2026 Ağustos'undaki Object Storage ve Functions ile 17 Eylül 2026'daki 'Neon backend GA' duyurusu Neon'u Supabase'in alanına taşıyor. Dokuz kritere bakacağız: branching/CI, scale-to-zero, auth, storage/realtime/functions, fiyat, bağlantı havuzlama, self-host, bölge ve sahiplik riski. Kısa cevap: auth+storage+realtime isteyenler için Supabase daha olgun; yalnızca Postgres isteyenler için Neon teknik olarak daha güçlü.

Karşılaştırma Matrisi

Karşılaştırma Matrisi: Supabase / Neon
ÖzellikSupabaseNeon
Branch tipiMigration-tabanlı, varsayılan verisiz (seed ya da 'Include data')Storage-seviyesi copy-on-write klon (prod veri) (Öne çıkan)
Desteklenen PG major sürümleri15-17 (PG14 desteği 1 Tem 2026'da bitti)14-18 (PG19 yol haritasında) (Öne çıkan)
Scale-to-zero / uyanmaFree: 1 hafta sonra pause, manuel unpause5 dk sonra askıda, ~ms içinde uyanma (Öne çıkan)
Auth olgunluğuGA, passkeys beta (2026-06) (Öne çıkan)Managed Better Auth, GA (17 Eyl 2026)
StorageGA, RLS destekli, geniş bölge (Öne çıkan)GA, branch'lenebilir, 4 AWS bölgesi
RealtimeGA — Broadcast/Presence/Postgres Changes (Öne çıkan)GA ürün yok; Electric tabanlı real-time sync yol haritasında
Edge/serverless fonksiyonEdge Functions (Deno, GA)Neon Functions (Node.js, veriye komşu, genişliyor)
Fiyat modeliSabit tier + kullanım-üstü (Pro $25/ay)Compute-saniye ($0.106/CU-saat Launch)
Bağlantı havuzu limiti5 strateji, plana göre değişirPgBouncer, 10.000 eşzamanlıya kadar (Öne çıkan)
Bölge sayısı17 spesifik AWS bölgesi (Öne çıkan)8 AWS bölgesi, sonradan değiştirilemez
Self-hostDocker Compose, tam self-host (özellik kaybıyla) (Öne çıkan)Resmi rehber bulunamadı (belirsiz)
GitHub yıldızı≈110,6 bin (23 Eyl 2026) (Öne çıkan)≈23,1 bin (23 Eyl 2026)
Şirket sahipliğiBağımsız (2026-06 Series F $500M) (Öne çıkan)Databricks bünyesinde (2025-05 satın alma)
LisansApache-2.0Apache-2.0
PG sürüm politikasıMajor+minor birlikte, eski major desteği kesiliyorSon 5 major, yalnız güncel minor

Derinlemesine İnceleme

Supabase

Genel Bakış

Supabase, 2020'de Y Combinator'dan çıkan ve Postgres'i merkeze alarak Firebase'e açık kaynak alternatif olmayı hedefleyen bir backend platformu olarak kuruldu. Zamanla Auth, Storage, Realtime (Broadcast+Presence+Postgres Changes) ve Deno tabanlı Edge Functions eklenerek tek başına bir 'backend' haline geldi — hepsi aynı Postgres üzerine, RLS ile entegre. 2026'da iki koldan genişliyor: Pipelines (Postgres→BigQuery CDC) ve Unified Logs; kurumsal tarafta Okta-yönetilen MCP erişimi ve Gemini Enterprise connector'ü. 2026-06'daki $500M Series F turu bağımsız kaldığını gösteriyor — Databricks çatısındaki Neon'un aksine roadmap tek platforma bağlı değil. Docker Compose self-host lock-in riskini düşürüyor, ama branching gibi bazı özellikler self-host'ta bilinçli dışarıda bırakılmış.

Ekosistem

Paket yöneticisi
npm (@supabase/supabase-js)
Geliştirme ortamı
VS CodeCursorSupabase Studio (web dashboard)
Popüler kütüphaneler
@supabase/ssr@supabase/auth-helperssupabase-flutterpostgrest-js
GitHub yıldızı
110,639

Neon

Genel Bakış

Neon, 2021'de storage ve compute katmanlarını ayırarak Postgres'i bulut-native hale getirmek için kuruldu — bu mimari saniyeler içinde branch açmayı (copy-on-write) ve kullanılmadığında sıfıra inmeyi (scale-to-zero) mümkün kıldı. 14 Mayıs 2025'te Databricks satın aldı; o günden beri 'Lakebase Postgres' teklifinin motoru — yol haritası artık bağımsız değil, Databricks'in Lakehouse stratejisine bağlı. 2026 Ağustos'u sıçrama ayı oldu: proje-izinleri, branch'lenebilir Neon Object Storage, veriye komşu Neon Functions, Electric ekibinin katılımı ve ay sonu 'Autoscaling Lakebase Postgres' duyurusu art arda geldi. 17 Eylül 2026'da ise 'Neon backend GA' duyuruldu: Lakebase Postgres, Object Storage, Functions, Managed Better Auth ve AI Gateway'in hepsi GA. Bu genişleme Neon'u tek neon.ts dosyasından branch'lenen tam backend'e dönüştürüyor — doğrudan Supabase'in alanına giren bir hamle.

Ekosistem

Paket yöneticisi
npm (@neondatabase/serverless), neon CLI (`neonctl` alias)
Geliştirme ortamı
VS CodeNeon Console (web dashboard)
Popüler kütüphaneler
@neondatabase/serverlessdrizzle-orm@prisma/adapter-neon
GitHub yıldızı
23,123

Teknik Analiz

Branching ve CI/CD Entegrasyonu

Neon'da bir branch, storage seviyesinde gerçek bir copy-on-write klon: ana branch'e ek yük bindirmeden, prod verisinin anlık görüntüsünü saniyeler içinde alıyorsun. Vercel entegrasyonu her preview deployment için otomatik branch açıyor; CLI/API/GitHub Actions ile CI'ya bağlanıyor. 17 Eylül 2026'daki "Neon backend GA" ile Auth, Storage, Functions ve AI Gateway dahil tüm backend tek neon.ts dosyasından tanımlanıp neon deploy ile branch'lenebiliyor. Supabase'de tablo farklı: yönetilen platformda branching migration-tabanlı ve doküman deyimiyle "data-less by default" — yeni branch varsayılan olarak ana projenin verisiyle veya storage nesneleriyle başlamıyor. Bir seed dosyası ya da dashboard'dan branch açarken "Include data" seçeneğiyle veriyi dahil edebiliyorsun, ama bu Neon'un storage-seviyesi copy-on-write klonu kadar anlık ve ucuz değil. Self-hosted Supabase dokümantasyonu açıkça "branching self-host'ta kullanılamaz" diyor. Pratik sonuç: "her PR'a production verisiyle izole ortam" gerekiyorsa Neon'un copy-on-write yaklaşımı teknik olarak daha güçlü. Supabase'in branch'i "şemam doğru deploy oluyor mu" sorusuna cevap verir ama gerçek veriyle davranışı Neon kadar test etmez.

Scale-to-Zero ve Soğuk Başlatma

İki platform da "kullanmadığında ödeme" felsefesini paylaşıyor ama uygulama biçimleri çok farklı. Neon'da scale-to-zero varsayılan olarak 5 dakikalık inaktivite sonrası devreye giriyor: compute askıya alınıyor, sonraki istekte birkaç yüz milisaniyede yeniden ayağa kalkıyor. Free planda bu davranış sabit; paid planlarda kapatılabilir. Tek istisna: logical replication subscriber'ın varlığı scale-to-zero'yu devre dışı bırakıyor. Supabase'de mekanizma farklı: Free plan projeleri 1 hafta inaktivite sonrası "paused" duruma geçiyor — manuel ya da otomatik unpause gerektiren, Neon'un saniyeler içindeki uyanmasından çok daha yavaş bir model. Kimin için önemli: düzensiz trafikli dev/staging projelerinde Neon'un saniyeler içinde uyanan modeli kullanıcı deneyimini bozmadan tasarruf sağlar. Supabase'in haftalık pause'u aktif projelerde daha az sorun çıkarır ama uzun süre dokunulmayan demo projelerinde sürpriz yaratabilir.

Auth Çözümü Olgunluğu

Supabase Auth platformun en olgun parçalarından: JWT tabanlı oturum, password/magic-link/OTP/social/SSO girişleri, geniş üçüncü taraf sağlayıcı desteği (Apple, Azure, Bitbucket) ve RLS entegrasyonu. 2026 Haziran'da passkeys beta'ya geçti. Neon Auth çok daha genç: "Managed Better Auth" adıyla sunulan, açık kaynaklı Better Auth üzerine kurulu native bir servis. Kimlik verisi doğrudan neon_auth şemasında saklanıyor — veritabanını branch'lediğinde auth state de birlikte dallanıyor. Framework quickstart'ları hazır, Google OAuth credential'ı gelmiş. Resmi roadmap sayfası servisi "generally available" olarak işaretliyor; 17 Eylül 2026 GA duyurusu Managed Better Auth'u da kapsıyor. Ama aynı sayfa devam eden çalışmayı da listeliyor: Organization plugin'i kısmi destekli, frontend ile backend'in ayrı deployment olduğu mimariler henüz desteklenmiyor. Pratik ölçüt: geniş bir sağlayıcı yüzeyine ve yıllara yayılmış saha geçmişine bugün ihtiyacın varsa Supabase Auth daha güvenli. Auth'un branch ile dallanması sana değer katıyorsa Neon Auth artık GA bir seçenek — yalnız mimarinin desteklenen framework listesine (Next.js, Vite + React, React Router, TanStack Router) uyduğunu baştan doğrula.

Storage, Realtime ve Edge Functions

Burada olgunluk farkı en net görülüyor. Supabase'de Storage (RLS destekli), Realtime (Broadcast+Presence+Postgres Changes) ve Edge Functions (Deno, açık kaynak) — üçü de yıllardır GA, geniş bölge kapsamında ve RLS ile sıkı entegre. Neon'da bu üçlü yeni şekilleniyor. Neon Object Storage 2026 Ağustos başında duyuruldu ve resmi blogun kendi başlığıyla artık "generally available": S3-uyumlu, branch'lenebilir — ama yalnız 4 AWS bölgesinde (Ohio, N. Virginia, Frankfurt, Singapore). Neon Functions veriye komşu Node.js compute çalıştırıyor; Object Storage'a dosya yüklendiğinde tetiklenen "Function Triggers" sonradan eklendi. Hepsi 17 Eylül 2026'daki "Neon backend GA" şemsiyesinde: tek neon.ts dosyasında Auth+Storage+Functions+AI Gateway. Anlamı: Neon mimari olarak doğru yönde ve bileşenler GA — ama hiçbiri Supabase'in yıllardır production'da duran eşdeğerleri kadar uzun bir saha geçmişine sahip değil, Object Storage'da bölge kapsamı da dar. Realtime tarafında ise Neon'un ayrı bir GA ürünü yok; Electric sync engine tabanlı gerçek zamanlı Postgres senkronizasyonu yol haritasında. Ağır storage/realtime yükü taşıyan uygulamada Supabase bugün daha güvenli zemin.

Fiyatlandırma ve Bağlantı Havuzlama

Supabase sabit tier + kullanım-üstü kullanıyor: Free $0, Pro $25/ay, Team $599/ay, Enterprise özel; compute add-on'ları Micro $10'dan 16XL $3.730'a kadar, MAU/disk/egress aşımları ayrı faturalanıyor. Öngörülebilir bir model. Neon compute-saniye bazlı: Free $0 (proje başına ayda 100 CU-saat), Launch $0.106/CU-saat ("tipik harcama $15/ay"), Scale $0.222/CU-saat. Düzensiz trafikte (scale-to-zero ile) Supabase'den ucuz çıkabilir ama öngörülebilirliği daha düşük. Bağlantı havuzlamada Neon net: PgBouncer tabanlı, 10.000 eşzamanlı bağlantıya kadar; max_connections 104'ten (0.25 CU) 4.000'e (9-56 CU) değişiyor. Supabase 5 farklı strateji sunuyor (Data API, Shared pooler transaction/session mode, Direct, Dedicated pooler) — esnek ama Neon'un tek modeline göre daha fazla karar gerektiriyor. Prisma/Drizzle ile pooler transaction-mode'da prepared statement uyumsuzluğu her iki platformda da bilinen bir sorun, ?pgbouncer=true gibi ek ayar istiyor.

Self-Host, Bölge Seçenekleri ve Kurumsal Sahiplik Riski

Supabase net: Docker Compose ile tam self-host, telemetri yok — ama branching, gelişmiş metrik, yönetilen backup+PITR, analytics gibi özellikler self-host'ta yok, operasyon sorumluluğu sende. Neon'da resmi, adım-adım bir self-host Docker rehberine bu araştırmada ulaşılamadı — yalnız "tam Postgres uyumluluğu, proprietary lock-in yok" vurgusu bulundu. Standart pg_dump/pg_restore ile taşınabilir olsa da kendi altyapısını çalıştırma seçeneği Supabase kadar net belgelenmemiş — belirsiz. Bölgede Supabase daha geniş: 17 spesifik AWS bölgesi. Neon 8 bölgeyle çalışıyor ve proje sonrası bölge değiştirilemiyor. En stratejik kriter: kurumsal sahiplik riski. Neon, 14 Mayıs 2025'te Databricks tarafından satın alındı; "Lakebase Postgres, by Databricks" olarak konumlanıyor, destek planları Databricks katmanlarına bağlı — roadmap artık bağımsız değil. Supabase 2026-06'daki $500M Series F ile bağımsız kalıyor. 3-5 yıllık bir platform kararı veriyorsan bu maddeyi teknik kriterler kadar ciddiye al.

Hangi Senaryoda Hangisi

Yeni bir SaaS MVP'si kuruyorsun, tek geliştiricisin, hızlı çıkmak istiyorsun

Öneri: Supabase

Auth, Storage, Realtime tek dashboard'dan hazır geliyor — ayrı servisleri entegre etmeye harcayacağın zamanı ürün geliştirmeye ayırabilirsin.

Ekibin her PR'da gerçek production verisiyle izole bir preview ortamı istiyor

Öneri: Neon

Storage-seviyesi copy-on-write branching + Vercel entegrasyonu, bu iş akışını Supabase'in migration-tabanlı branch'ine göre çok daha gerçekçi kurar. Supabase'de branch varsayılan olarak verisiz; veriyi seed dosyasıyla ya da dashboard'daki 'Include data' seçeneğiyle alabilirsin ama bu anlık bir klon değil.

KVKK/GDPR nedeniyle self-host zorunlu, ama branching'e ihtiyacın yok

Öneri: Supabase

Docker Compose ile tam self-host, telemetri yok. Neon için resmi bir self-host rehberi bu araştırmada bulunamadı.

Trafiğin çok düzensiz (demo, staging, side-project), maliyeti minimumda tutmak istiyorsun

Öneri: Neon

Scale-to-zero (5 dk, ms içinde uyanma) + compute-saniye fiyatlandırma, Supabase'in haftalık pause + sabit tier modeline göre daha ince taneli tasarruf sağlar.

Kurumsal bir müşterisin, tedarikçi roadmap'inin bağımsız olması senin için sözleşme/risk maddesi

Öneri: Supabase

2026 Haziran'da $500M Series F ile bağımsız kalmaya devam ediyor. Neon, 2025'ten beri Databricks bünyesinde — roadmap Lakehouse stratejisine bağlı.

Databricks/Lakehouse ekosistemiyle zaten çalışıyorsun, veri ekiplerin orada

Öneri: Neon

Neon artık Databricks'in Lakebase Postgres motoru — mevcut Databricks entegrasyonların ve iş akışlarınla doğal olarak örtüşür.

Uygulaman ağır dosya yükleme + canlı güncelleme (chat, presence) gerektiriyor

Öneri: Supabase

Storage ve Realtime yıllardır GA ve geniş bölge kapsamında. Neon Object Storage de GA ama 4 AWS bölgesiyle sınırlı ve çok daha yeni; Neon'da ayrı bir realtime ürünü yok, Electric tabanlı sync henüz yol haritasında.

Yaygın Tuzaklar

  • Prisma/Drizzle ile pooler'ın transaction-mode'unda 'prepared statement does not exist' hatası almak

    Her ikisi

    Çözüm

    Bağlantı string'ine ?pgbouncer=true (Prisma) veya sürücü ayarında statement_cache_size=0 ekleyerek prepared statement cache'ini kapat — hem Supabase Supavisor hem Neon PgBouncer'da geçerli.

  • Neon'da proje oluştururken bölgeyi düşünmeden varsayılanı kabul etmek

    Neon

    Çözüm

    Proje oluşturulduktan sonra bölge değiştirilemez; taşımak yeni proje + migrasyon gerektirir. Kullanıcı tabanının coğrafi ağırlık merkezine göre bölgeyi baştan seç.

  • Supabase self-host'a geçip branching'in de geleceğini varsaymak

    Supabase

    Çözüm

    Resmi dokümantasyon self-host'ta branching'in kullanılamadığını açıkça belirtiyor — self-host kararını bu kısıtı bilerek ver, CI/CD akışını buna göre tasarla.

  • Neon Auth'u (Managed Better Auth) frontend ve backend'i ayrı domain'lerde duran bir mimariye kurmaya çalışmak

    Neon

    Çözüm

    Servis GA olsa da resmi roadmap, frontend ile backend'in ayrı deployment olduğu mimarilerin henüz desteklenmediğini açıkça yazıyor: oturum yönetimi HTTP-only cookie ile yapılıyor ve bu cookie'ler farklı domain'ler arasında güvenli paylaşılamıyor. Desteklenen framework'lerden (Next.js, Vite + React, React Router, TanStack Router) biriyle başla, gereken plugin'lerin destek durumunu da roadmap'ten doğrula.

  • Supabase Free plan projesinin 1 hafta sonra pause olacağını unutup demo günü sürpriz yaşamak

    Supabase

    Çözüm

    Demo/staging projelerini Pro plana taşı ya da düzenli bir health-check cron'u ile projeyi aktif tut; pause sonrası unpause manuel müdahale gerektirebilir.

Geçiş Kılavuzu

Supabase → Neon (veya tersi)

Tahmini süre: Yalnız veritabanı için 1-2 gün; Auth/Storage/Realtime dahil tam backend taşıması için 1-3 hafta (ekip büyüklüğüne ve entegrasyon derinliğine göre değişir)
  1. 1Şemayı ve verini pg_dump --format=custom ile dışa aktar (her iki platform da standart Postgres olduğu için bu adım platformdan bağımsız çalışır)
  2. 2Hedef platformda yeni proje aç ve bölgeyi kesinleştir (Neon'da proje sonrası bölge değiştirilemez)
  3. 3pg_restore ile şema+veriyi hedef veritabanına yükle, sonra ANALYZE çalıştır
  4. 4Auth'u yeniden kur: Supabase Auth kullanıyorsan Neon Auth'a (Managed Better Auth, 17 Eyl 2026'dan beri GA) veya bağımsız bir auth sağlayıcısına geçiş planı yap; Neon Auth'tan Supabase Auth'a geçiyorsan kullanıcı tablolarını ve şifre hash'lerini uyumlu formata dönüştür
  5. 5RLS politikalarını (Supabase) veya branch-bazlı auth şemasını (Neon) hedef platformun modeline göre yeniden yaz — otomatik taşınmazlar
  6. 6Storage dosyalarını (varsa) hedef platformun S3-uyumlu depolamasına (Neon Object Storage) veya Supabase Storage'a kopyala, imzalı URL'leri güncelle
  7. 7Bağlantı string'lerini ve pooler ayarlarını (Supavisor ↔ PgBouncer) güncelle, ORM prepared-statement ayarlarını yeniden test et
  8. 8Staging ortamında tam bir E2E test geçir, sonra DNS/env değişkenlerini production'a yönlendir

Gelecek Öngörüsü

Supabase

Supabase, 2026 içinde Pipelines'ı (Postgres→BigQuery CDC) genel kullanıma açmayı ve ClickHouse/Snowflake/DuckLake hedeflerini genişletmeyi planlıyor; Unified Logs open beta'dan GA'ya geçiyor; kurumsal tarafta Okta-yönetilen MCP erişimi ve Gemini Enterprise connector'ü ile AI-ajan entegrasyonlarına yatırım sürüyor (supabase.com/blog).

Neon

Neon, Databricks çatısı altında 17 Eylül 2026'da ilan ettiği 'Neon backend GA' hattını (Auth+Storage+Functions+AI Gateway tek neon.ts dosyasından branch'lenebilir) genişletiyor; resmi yol haritası Electric sync engine tabanlı gerçek zamanlı Postgres senkronizasyonunu, PG19 desteğini, ücretli planlar için bölge genişlemesini ve Konsol'da RBAC'i listeliyor; roadmap artık Databricks'in Lakehouse/Lakebase stratejisiyle senkronize ilerliyor (neon.com/blog, databricks.com/blog).

Altın Bilgi

En değerli çıkarım şu: 2026 Ağustos'unda Neon'un art arda yayınladığı Object Storage ve Functions duyuruları ile 17 Eylül 2026'daki "Neon backend GA" ilanı tesadüf değil — Databricks'in satın almasından sonra Neon bilinçli olarak Supabase'in alanına giriyor. "GA" etiketi artık iki tarafta da var; fark yaş farkı: Supabase bu bileşenleri yıllardır production'da çalıştırıyor, Neon'un eşdeğerleri Eylül 2026'da GA oldu — aynı olgunlukta değiller. Daha stratejik katman: Neon'un roadmap'i artık kendi şirketinin değil, Databricks'in Lakehouse önceliklerinin parçası. 3-5 yıllık bir karar veriyorsan "bu özellikler benim için mi, Databricks'in stratejisi için mi" sorusunu sor.

İlgili Blog Yazıları

Tüm Yazıları Gör

İlgili İçerik