RadarGitHub Radarai üretimi

GitHub Radar — Neon

PostgreSQL'in yerel disk bağımlılığını kırarak hesaplama ve depolamayı ayıran, Rust ile yazılmış sunucusuz ve dallanabilir depolama motoru.

Neon, modern bulut yerel ve sunucusuz (serverless) mimariler için PostgreSQL’in monolitik depolama katmanını yerel diskten söküp alan, hesaplama (compute) ile depolamayı (storage) birbirinden tamamen ayıran açık kaynaklı bir sunucusuz veritabanı platformudur 1. Geleneksel PostgreSQL kurulumlarının sanal sunucularda sabit disk boyutları, sürekli çalışan atıl CPU maliyetleri ve dakikalar süren veritabanı klonlama operasyonları yarattığı kurumsal senaryolara karşı Neon; Rust ile yazılmış dağıtık sayfa sunucusu (pageserver), Paxos tabanlı işlem günlüğü (safekeeper) ve Git benzeri anlık veritabanı dallanması (branching) sunan yeni nesil bir depolama motorudur 2.

Açık kaynaklı veri tabanı altyapıları arasında 23 bin yıldız ve son commit 1 gün önce düzeyinde küresel bir ölçeğe ulaşan repo, aktif olarak yönetilen 301 açık issue ve kesintisiz kurumsal dağıtım temposunu yansıtan son sürüm release-proxy-8853 (Eylül 2026) metrikleriyle canlılığını kanıtlamaktadır.

Mimari Deep-Dive: Neon

Neon’un arkasındaki temel mimari atılım, PostgreSQL’in çeyrek asırlık yerel blok aygıtı varsayımını geçersiz kılıp depolama mantığını çekirdekten ayırmasından (disaggregation) kaynaklanır. Sistem iki ana katmandan oluşur: Sorguları çalıştıran durumsuz (stateless) PostgreSQL hesaplama düğümleri ve bu düğümlerin arkasında çalışan, tamamen Rust diliyle geliştirilmiş dağıtık Neon depolama motoru 1. Depolama motorunun Rust ile yazılması; C tabanlı bellek hatalarını derleme zamanında engellemek, eşzamanlı G/Ç işlemlerini Tokio çalışma zamanıyla kilitsiz yürütmek ve nesne depolama (S3) ile yerel NVMe önbellekleri arasında mikro-saniye seviyesinde veri sayfaları sentezlemek için zorunlu bir tercihtir.

Geleneksel PostgreSQL, tabloları yerel dosya sisteminde 8 kilobaytlık sayfalar halinde saklar ve her değişikliği yerel diske WAL (Write-Ahead Log) olarak yazar. Neon bu mimariyi kökünden değiştirir. Hesaplama düğümünde yerel veri diski bulunmaz; yapılan yazma işlemleri ağ üzerinden safekeeper adı verilen dağıtık konsensüs düğümlerine aktarılır. Safekeeper kümesi, Paxos protokolüyle çoğaltılan bir WAL hizmetidir; işlem günlüğü çoğunluk tarafından onaylandığı anda işlem tamamlanır (commit).

İkinci kritik bileşen ise pageserver katmanıdır 3. Pageserver, safekeeper düğümlerinden akan WAL kayıtlarını toplayarak LSM-tree benzeri katmanlı bir veri yapısında saklar. Hesaplama düğümünün bellek içi tamponunda (shared buffers) bir sayfa bulunamadığında, işletim sisteminden okuma yapmak yerine ağ üzerinden GetPage@LSN çağrısı yapar. Pageserver, istenen sayfanın tam olarak belirtilen Günlük Sıra Numarasındaki (LSN) durumunu anında yeniden oluşturup hesaplama düğümüne döndürür.

Bu mimarinin en radikal getirisi kopyala-yaz (copy-on-write) tabanlı anlık veritabanı dallanmasıdır (database branching). Yeni bir dal açıldığında tüm veritabanı kopyalanmaz; yalnızca üst dalın ayrılma anındaki LSN değeri (ancestor_lsn) kaydedilir. Saniyeler içinde açılan yeni dal, başlangıçta sıfır disk alanı tüketir ve yalnızca yazılan yeni deltaları depolar. Arka planda ise pageserver eski sayfaları düzenli olarak temel görüntülere (base images) dönüştürüp Amazon S3 uyumlu nesne depolarına aktarır; bu sayede hesaplama düğümleri trafik olmadığında saniyeler içinde sıfıra uyutulabilir (scale-to-zero). İlk gelen bağlantı isteğinde SNI/TLS vekil sunucusu (proxy) hesaplama düğümünü milisaniyeler içinde canlandırarak istemciye hissettirmeden oturumu başlatır.

Kod ve Topluluk Sağlığı

Neon, PostgreSQL çekirdek geliştiricilerinden Heikki Linnakangas ve MemSQL kurucularından Nikita Shamgunov liderliğinde kurulan Neon Inc. şirketi ve kıdemli veritabanı mühendislerinden oluşan bir ekip tarafından yönetilmektedir 1. Proje, Databricks gibi sektör devlerinin stratejik yatırımlarıyla desteklenen devasa bir kurumsal arka plana sahiptir.

Depodaki açık issue sayısının 300 bandında tutulabilmesi, 23 bin yıldızlı böylesine karmaşık bir dağıtık motor için yüksek bir mühendislik disiplinine işaret eder. Çekirdek depoya sunulan PR’lar; çoklu PostgreSQL sürüm matrisi (PG 14, 15, 16, 17), safekeeper Paxos bölünme simülasyonları, Jepsen benzeri ağ arıza enjeksiyonları ve yoğun bellek sızıntısı testlerinden geçer 4. Maintainer ekibi topluluk tartışmalarına ve mimari geri bildirimlere doğrudan katılarak şeffaf bir RFC süreci yürütmektedir. Sürümleme takvimi sürekli dağıtım (continuous delivery) prensibiyle işletilir; proxy, pageserver ve safekeeper bileşenleri düzenli etiketlerle canlıya alınır. health_score bu bölümden türer: issue kapanma hızı, sürüm düzeni, bakımcı ekibi. Ajanın tahminidir; künyede öyle yazılır. Projenin PostgreSQL çekirdeğine olan derin hakimiyeti, kararlı finansal desteği ve şeffaf issue yönetimi dikkate alınarak mimari güvenilirlik skoru health_score: 9.1 olarak takdir edilmiştir.

Production Riski: Gerçekten Kullanılır mı?

Neon’u üretim mimarisine dahil etmeyi planlayan sistem mimarları için lisanslama tarafında kurumsal risk bulunmamaktadır; projenin depolama motoru ve bileşenleri tamamen açık kaynaklı Apache 2.0 lisansı ile dağıtılmaktadır 5. Kendi altyapınızda barındırmanız (self-hosting) durumunda herhangi bir ticari kısıtlama veya gizli lisans tuzağı yoktur.

Neon’un üretimde hayat kurtardığı senaryolar son derece belirgindir: CI/CD boru hatlarında her PR için saniyeler içinde üretim verisinin tam bir kopyasını açıp test etmek, binlerce kiracılı SaaS platformlarında atıl veritabanlarını sıfıra uyutarak bulut faturasını dramatik biçimde düşürmek ve geçmişe dönük (point-in-time) veri kurtarma operasyonlarını anında gerçekleştirmek.

Buna karşın, operasyonel ödünleşimlerin bilincinde olmak gerekir. İlk kısıt, analitik ve soğuk veri sorgularıdır; yerel NVMe SSD’ye sahip geleneksel bir PostgreSQL sunucusuna kıyasla, soğuk sayfa önbelleğiyle çalışan devasa sıralı taramalarda (sequential scan) pageserver ile hesaplama düğümü arasındaki ağ gecikmesi sorgu süresini uzatabilir. İkinci kısıt ise kendi altyapınızda çalıştırmanın (self-hosting) operasyonel karmaşıklığıdır; proxy, safekeeper kümesi, pageserver, storage broker ve S3 depolamasını yüksek erişilebilirlikle orkestre etmek ileri düzey Kubernetes ve sistem uzmanlığı gerektirir. Bu sınırlar gözetildiğinde Neon, bulut yerel OLTP iş yükleri ve geliştirici deneyimi için tartışmasız en devrimci açık kaynak veritabanı mimarilerinden biridir.

Kaynaklar

  1. Neon GitHub Ana Deposu
  2. Neon Resmi Web Sitesi ve Dokümantasyonu
  3. Neon Mimari Sözlüğü ve Pageserver Detayları
  4. Neon GitHub Tartışmaları ve Topluluk Etkileşimi
  5. Neon Apache 2.0 Lisans Dosyası