Neon

Kısaca: Bir “sunucusuz Postgres” sağlayıcısı — gerçek bir PostgreSQL veri tabanı, ancak kendi sunucunu yönetmeden, elle kurulum yerine bir bağlantı dizgisi kullanarak.

Biraz daha ayrıntılı: Panoda, istediğin zaman düz metin olarak görüntülenebilen bir bağlantı dizgisi (“Connection Details”) alırsın (örneğin yalnızca bir kez gösterilen bir API anahtarının aksine). Teknik olarak pg_dump/psql gibi standart araçlarla uyumlu, tamamen sıradan SQL çalıştırır.

Ayrıntılı

Depolama ve hesaplamanın ayrılması

Neon, depolamayı ve hesaplamayı teknik olarak ayırır: asıl veriler dağıtık bir depolama katmanında yaşar (dahili olarak Postgres’in klasik dosya sistemi düzeni değil, log yapılı depolamaya dayanan özel yapım bir sistem), isteklere yanıt veren “hesaplama” örneği — asıl PostgreSQL süreci — ise hiç veri kaybı olmadan gerektiğinde başlatılıp kapatılabilir. Neon Auto-Suspend’i mümkün kılan tam olarak budur ve 7/24 çalışan tam bir sunucu kiralayan klasik barındırmadan (örneğin AWS’de klasik bir RDS örneği veya kendi yönettiğin bir Postgres sunucusu) temel farktır. Bu mimari, son yıllarda veri tabanı barındırmadaki daha geniş bir eğilimin parçasıdır — “sunucusuz Postgres” — ki Neon’un yanı sıra Postgres etrafında ek olarak auth, depolama ve gerçek zamanlı özellikleri paketleyen Supabase gibi sağlayıcıları veya AWS Aurora Serverless’i de kapsar; ancak depolama ile hesaplama arasındaki ayrımın derinliği değişir.

Dallanma

Klasik bir Postgres kurulumunda bu biçimde bulunmayan bir özellik: dallanma (branching). Üretim veri tabanının eksiksiz bir kopyasını (“dal”) istediğin zaman oluşturabilirsin; bu başlangıçta pratikte ek depolama maliyeti getirmez (copy-on-write — yeni bloklar yalnızca daldaki veriler gerçekten değiştiğinde yazılır). Bu, örneğin riskli bir migrasyonu gerçek üretim veri tabanında çalıştırmadan önce önce bir kopyada test etmek ya da her pull request önizleme dağıtımı için otomatik olarak ayrı, yalıtılmış bir veri tabanı kopyası oluşturmak için yararlıdır (yaygın bir CI/CD kalıbı: PR başına bir dal, PR birleştirilince/kapatılınca otomatik silinir). Dallar panodan olduğu kadar Neon CLI/API üzerinden de oluşturulabilir; bu, otomatik dağıtım hatlarına iyi uyum sağlar.

Bağlantı dizgisi ve havuzlama

Bağlantı dizgisi tipik olarak şu biçimdedir:

postgresql://<user>:<password>@<endpoint>.neon.tech/<database>?sslmode=require

Neon’da sslmode=require zorunludur — şifresiz bağlantılar sunucu tarafında reddedilir; yerelde yanlışlıkla bu bayrak olmadan bir bağlantıyı denersen bu, anlaşılması zor bir hata mesajına yol açabilir. Sunucusuz ortamlardan gelen bağlantılar için (örneğin istek başına potansiyel olarak yeni bağlantılar açan Vercel Functions), Neon ayrıca “işlem havuzlama” kipinde PgBouncer üzerinden (uygulama ile asıl Postgres örneği arasında duran ayrı bir bağlantı havuzlayıcısı) bir “havuzlu bağlantı” dizgisi sunar. Bu önemlidir, çünkü Postgres’in kendisi yalnızca sınırlı sayıda eşzamanlı bağlantıya izin verir (daha küçük hesaplama boyutlarında tipik olarak yüzlerin alt kısmı) — her biri kendi bağlantısını açan çok sayıda kısa ömürlü sunucusuz işlev çağrısıyla bu sınır aksi hâlde hızla tükenirdi (“bağlantı tükenmesi”). Havuzlu bağlantı dizgisinin dezavantajı: uzun ömürlü bir oturum gerektiren bazı Postgres özellikleri (örneğin LISTEN/NOTIFY, oturum sınırları arasında hazırlanmış ifadeler veya danışma kilitleri) işlem havuzlama kipinde güvenilir biçimde çalışmaz — bunlar için doğrudan, havuzsuz bağlantıya ihtiyaç vardır.

Alternatiflerle karşılaştırma

Supabase ile karşılaştırıldığında (çok daha geniştir, kendi auth sistemi ve depolama kovalarını da içerir), Neon bilinçli olarak yalın tutulmuştur — ek platform özellikleri olmadan, sunucusuz özelliklere sahip saf bir Postgres veri tabanı. PlanetScale ile karşılaştırıldığında (gerçek Postgres’e değil, MySQL uyumlu Vitess’e dayanır), Neon seni Postgres ekosistemiyle tamamen uyumlu tutar — “gerçek” Postgres ile konuşan her araç (pg_dump/psql dahil, bkz. pg_dump ve psql) değişmeden çalışır.

Ayrıca bak: pg_dump ve psql, Drizzle ORM