Rust ile Postgres yapmak — veritabanının LLVM’inden yararlanan bir yaklaşım

• Turso, Rust tabanlı veritabanı çekirdeğine Postgres uyumlu bir frontend bağlayarak, tek bir yürütme motorunun birden fazla veritabanı dilini işlediği veritabanının LLVM’i yapısına doğru genişliyor
• Postgres SQL’ini ortak bir AST’ye parse edip VDBE bytecode’una derliyor; fizibiliteyi doğrulayan pgmicro’yu ana kod ağacına birleştirerek resmî geliştirme temeli haline getiriyor
• Mevcut çekirdek, SQLite dosya uyumluluğu, MVCC ile eşzamanlı yazma, asenkron yürütme, zengin bir tip sistemi ve otomatik yenilenen materialized view desteği sunuyor; güvenilirliği de çeşitli test teknikleriyle doğrulanıyor
• Tarayıcı, mobil ve çeşitli cihazlarda gömülü ya da tek dosya olarak çalışırken, mevcut uygulamaların, ORM’lerin ve psql’in Postgres wire protocol üzerinden bağlanabilmesi için tasarlanıyor
• %100 birebir uyumluluk yerine, yaygın kullanılan temel özelliklerle mevcut uygulamaların çoğunu değişiklik yapmadan çalıştırmaya odaklanıyor; genişletmeler ve PL/pgSQL için WASM ve uyumluluk katmanı uygulanması değerlendiriliyor ve geliştirme MIT lisansı altında yürütülüyor

---

Turso üzerinde Postgres inşa etmenin nedeni

• Turso, Rust ile yazılmış modern bir veritabanı çekirdeği ve bunun üzerine sıfırdan Postgres uyumlu bir veritabanı inşa ediliyor
• Uzun vadeli hedef, mevcut Postgres’i yalnızca Rust’a taşımak değil, modern mimariye sahip yeni bir veritabanı oluşturmak
  • Her bağlantı için ayrı süreç kullanmıyor
  • Tarayıcı içinde gömülü olarak çalışabiliyor
  • Tek bir veritabanı tek dosya olarak ele alınabiliyor
  • Materialized view’lar ayrı işler olmadan otomatik yenileniyor
• Tek, kararlı bir çekirdeğe birden fazla frontend bağlanan değiştirilebilir derleme mimarisi hedefleniyor
  • İlk frontend SQLite
  • Bir sonraki resmî frontend Postgres
  • İleride MySQL, Redis veya deneysel veritabanları gibi frontend’ler de eklenebilir
• Ortaya çıkan şey şu an tamamlanmış bir ürün değil, gerçekten çalıştırılabilen bir geliştirme temeli aşaması

SQLite yeniden uygulamasından ortak veritabanı çekirdeğine

• Turso başlangıçta, SQLite’ın Rust ve modern mimariyle tamamen yeniden uygulanmasıydı; SQLite dosyalarını açıp oluşturabilen dosya uyumluluğunu koruyor
• SQLite’ın kapsamını aşan özelliklere de şimdiden sahip
  • Postgres gibi, MVCC ile eşzamanlı yazmayı destekliyor
  • Postgres’e benzer zengin bir tip sistemi sunuyor
  • Tamamen asenkron çalıştığı için tarayıcı gibi kısıtlı ortamlarda da yerel yürütmeye uygun
  • Materialized view’lar gerçek zamanlı olarak otomatik yenileniyor, bu yüzden REFRESH MATERIALIZED VIEW cron işleri veya tetikleyici kombinasyonları gerekmiyor
• Postgres frontend’i eklense de Turso ve SQLite için mevcut hedefler değişmiyor
  • SQLite ile tam uyumluluk ve gelecekteki iş yükleri için özellik genişletmeleri hedeflenmeye devam edecek
  • Gerekli özellikler uygulanırken Postgres testlerinden de yararlanılabildiği için geliştirme hızı artabilir

Güvenilirlik ve açık katkı modeli

• SQLite’ın sağlamlığını yeniden üretmek için güvenilirlik bir ürün özelliği olarak ele alınıyor
  • Deterministik simülasyon testleri kullanılıyor
  • Antithesis testleri yürütülüyor
  • Oracle testleri, fuzzing ve biçimsel yöntemler de birlikte uygulanıyor
• Turso’da şu anda 260’tan fazla katkıcı var ve dışarıdan gelenlerin de projenin yönüne katılabildiği açık katkı (Open Contribution) modeli işletiliyor
• Kod ve yüksek kalite standartlarını merkeze alan, sürekli katkı sunan kişilerin proje kararlarına da katıldığı Linux çekirdeği benzeri bir ortam hedefleniyor
• Yapay zeka tarafından yazılmış katkılar da kabul ediliyor, ancak yeterli kaliteyi taşıması; insanların da kodu dikkatle inceleyip mimariyi anlaması gerekiyor

SQLite içindeki VDBE sanal makinesi

• SQLite, SQL’i doğrudan çalıştıran tek katmanlı bir yapı değil; SQLite lehçesindeki SQL’i VDBE bytecode’una derleyip çalıştıran bir sanal makine mimarisine sahip
• VDBE, JVM, .NET veya WASM gibi genel amaçlı bir bytecode değil; B-tree’de öğe bulma gibi veritabanına özgü yüksek seviyeli işlemler sunuyor
• Bu bytecode dilinin dışarıya açık bir spesifikasyonu ya da modüler arayüzü yok, ancak SQLite içinde fiilen mevcut ve Turso da aynı tasarımı benimsiyor
• Turso VDBE’nin genelliğini doğrulamak için küçük bir C-to-VDBE derleyicisi ile Doom dönüştürüldü
  • Gerçek Turso motoru WASM’e derlenerek tarayıcı sekmesinde Doom’un VDBE bytecode’u çalıştırılıyor
  • Veritabanının SELECT işlemesini yaptığı mantıkla Doom çalıştırılıyor
  • Her kare tek bir sonuç satırı olarak işleniyor
  • Bellek alanları okunup yazılabilen blob’lar olarak temsil ediliyor
  • Uygulama turso-vdbe-doom-example deposunda görülebilir

Postgres frontend’inin derleme mimarisi

• Mevcut SQLite ve Postgres birleştirme girişimleri, SQLite’ın monolitik yapısı nedeniyle çoğunlukla Postgres sorgularını SQLite sorgularına çeviren bir sorgu katmanı çevirisi yaklaşımına dayanıyordu ve iki veritabanının dış davranış farkları nedeniyle ciddi bir uyumsuzluk vardı
• İçeride ise SQL veritabanlarının çoğu, B-tree ve indeks kümeleri etrafında benzer temel işlemler yürütüyor
• Postgres ile SQLite’ın depolama yapıları arasında belirgin farklar var
  • Postgres satırları heap dosyalarında tutar; ayrı B-tree indeksleri, tuple sürümleri, TID ve vacuum kullanır
  • SQLite veriyi B-tree içinde kümeler
• Bu farklar büyük ölçüde disk üzerindeki baytların yerleşiminden kaynaklanıyor ve Postgres’in ihtiyaç duyduğu işlemler mevcut VDBE ile ifade edilebilir ya da VDBE komutları genişletilerek desteklenebilir
• Yeni yapıda veritabanı frontend’leri değiştirilebilir
  1. Postgres dili ortak bir AST’ye parse edilir
  2. AST, Turso bytecode’una derlenir
  3. Ortak Turso çekirdeği bu bytecode’u yürütür
• Fizibiliteyi doğrulayan ilk deney pgmicro ile yapıldı; ardından sonuçlar Turso ana kod ağacına birleştirilerek resmî projeye dönüştürüldü

Çalışma biçimi ve kullanım senaryoları

• Hedef, aynı Postgres SQL’i ve veritabanı davranışını sunucusuz biçimde birden çok şekilde sağlamak
  • Tarayıcı sekmesinde gerçek Postgres uyumlu veritabanı çalıştırmak
  • Ajanların her kullanıcı için yeni bir veritabanı oluşturup her birini tek dosya olarak yönetmesi
  • Local-first uygulamaların Postgres verisini tek dosya olarak indirip sonra yeniden senkronize etmesi
  • Mobil telefonlarda ve çeşitli cihazlarda SQLite gibi gömülü şekilde çalıştırmak
• Mevcut Turso veritabanını yerel dosyaya senkronize etme özelliğinin de Turso/Postgres’te desteklenmesi planlanıyor
• Yalnızca tek dosya ve gömülü çalışma değil, wire protocol ve sunucu uygulaması da içerdiğinden mevcut uygulamalar, ORM’ler ve psql bağlanabilecek
• Yakın vadede Turso ekibinin doğrudan geliştireceği resmî frontend’ler SQLite ve Postgres olacak; diğer frontend’ler için yapı dış katkıcılara açık tutulacak

Şu an nasıl çalıştırılır ve nasıl katkı verilir

• Henüz yayımlanmış paket yok, ancak kaynak koddan doğrudan derlenip çalıştırılabiliyor

  cd postgres/cli && cargo run
  

• Postgres frontend’i ayrı bir depoda değil, Turso kod ağacının içinde ilk günden beri resmî frontend olarak geliştiriliyor
• Geliştirme ve katkılar Turso GitHub deposu üzerinden yürütülüyor

Uyumluluğun hedefi ve sınırları

• SQLite’a göre çok daha karmaşık olan Postgres yapısı nedeniyle %100 uyumluluk zorunlu bir hedef olarak alınmıyor
• Çekirdek ve yaygın kullanılan özellikleri yeterli düzeyde destekleyerek, kullanıcıların büyük çoğunluğunun uygulamalarını değiştirmeden çalıştırabilmesine odaklanılıyor
• Modern özelliklerle kusursuz 1:1 uyumluluk çatıştığında, karar özellik bazında veriliyor
  • Turso’nun materialized view’ları gerçek zamanlı otomatik yenileniyor
  • Sırf tam uyumluluk için otomatik yenilenmeyen eski modelin ayrıca uygulanıp uygulanmayacağı kesinleşmiş değil
• Özellik kapsamı büyüdükçe Turso/Postgres, bir Postgres kopyasından çok kendine özgü bir veritabanına yaklaşabilir

Yapay zeka kullanımı ve geliştirme hızı

• Yapay zeka araçları aktif biçimde kullanılıyor, ancak kod incelemesi ve mimariyi anlama adımları atlanmıyor
• Veritabanı gibi kritik bileşenlerde yapay zeka araçlarının doğrulama sorumluluğunu üstlenecek düzeye henüz ulaşmadığı düşünülüyor
• Fable’ı 24 saat çalıştırma yaklaşımına göre commit bazında hız daha düşük olabilir, ancak başlangıç noktası zaten çalışan ve kapsamlı biçimde test edilmiş bir veritabanı çekirdeği
• Sistemi hızlıca bozmak yerine yavaş ama doğru uygulama yaklaşımı tercih ediliyor
• Tüm özelliklerin tamamlanması zaman alacak ve bazı özellikler, uygun mimari yerine oturana kadar uzun bir geliştirme sürecinden geçecek

PL/pgSQL ve genişletmeler

• PL/pgSQL, uygulanamaz bir unsur değil bir prosedürel dil; ancak birebir yeniden uygulamak yerine ayrı bir prosedürel dil ve uyumluluk katmanı sunulması daha olası görülüyor
• Bazı Postgres genişletmelerini WASM konteynerinde yüklemeye dair bir kavram kanıtı elde edilmiş durumda
  • WASM konteynerinin sunduğu sembolleri kullanan genişletmeler keyfi biçimde yüklenebiliyor
  • WASM çalıştırmanın bir performans kaybı var
  • Bu yaklaşım henüz nihai tasarım olarak kesinleşmiş değil
• Keyfi kodun sınırsız yürütülmesine izin veren bir genişletme sistemi arzu edilir bulunmuyor
• Bazı genişletmeler desteklenemeyebilir, ancak birçoğunun WASM’e derlenerek yüklenebileceği düşünülüyor

Beklenen takvim ve açık kaynak stratejisi

• Sıfırdan yeni bir veritabanı yapmak yerine, hâlihazırda çalışan, test edilmiş ve Postgres ile iç yapısının önemli bölümünü paylaşan bir çekirdekten başlanıyor
• Tüm Postgres özelliklerini uygulamak uzun zaman alabilir, ancak pratikte faydalı olacak yeterince büyük bir özellik alt kümesinin birkaç ay içinde sunulabileceği öngörülüyor
• İki ana geliştirici şu anda yaklaşık 44 yaşında ve en az 20 yıl daha geliştirme yapabileceklerini düşündükleri için tüm özellikleri aceleyle tamamlama baskısı taşımıyor
• Gerçek geliştirme hızı ve kapsam, büyük ölçüde topluluk katkılarına bağlı olacak
  • SQLite lehçesinde çoklu süreç desteği geliştirilirken ekipte Windows makinesi olmadığı için Windows uygulaması kapsam dışı bırakılmıştı
  • Turso’yu yoğun kullanan harici bir geliştirici ilgi gösterip bir hafta içinde Windows desteğini tamamladı
• Deneysel frontend’ler kod ağacının dışında geliştirilebilir, ancak resmî Postgres frontend’i için mevcut Turso ile aynı MIT lisansı uygulanıyor

[GN⁺]

Lobste.rs yorumları

• Neredeyse tüm SQL veritabanları sorguları sanal makine (VM) için derlemiyor mu diye düşünüyorum.
  Bu açıdan özellikle SQLite’ı öne çıkarmak biraz tuhaf görünüyor.

  • Çoğu veritabanı bir ilişkisel işlem ağacı oluşturur ve her işleme push ya da pull arayüzü koyar.
    Buna karşılık SQLite, sorguları değişkenler ve döngüler içeren imperative bytecode’a derler.

• pgwire geliştiricisi olarak, Turso’nun PostgreSQL uyumlu veritabanında pgwire’ı yeniden kullanacak olmasına sevindim.

• Şirketin neden yön değiştirmenin gerekli olduğuna karar verdiğini merak ediyorum.

• SQLite yeniden uygulamasını tamamladılar mı, yoksa vaz mı geçtiler merak ediyorum.
  https://lobste.rs/s/rxdnnq/introducing_first_alpha_turso_next

  • https://github.com/tursodatabase/turso/…
    Görünüşe göre hâlâ o hedefi korurken araya başka frontend’ler de ekliyorlar.

• Çok ilginç bir yazı; haksız yere bildirilmiş olması utanç verici.

  • Bir gün iş projemin seyrini değiştirebilecek kadar etkisi büyük bir teknoloji.
    Kesinlikle “off-topic” ya da “spam” değil; neden öyle bildirdiklerini hiç anlayamıyorum.
    Yazıda bir tane tire var diye yapay zeka çöpü olduğuna mı hükmettiler bilmiyorum; insanlar gerçekten aklını kaçırıyor gibi.
    Bu sitenin bildirim kültürü berbat hale geldi; yöneticilerin müdahale etmesini isterim. Kötü niyetle bildirim yapan birkaç kişiyi engellerlerse belki geri kalanlar da kendini dizginler.
  • Artık haksız bildirim başlı başına buranın kültürü haline gelmiş durumda.

• Eskiden beri Turso’nun SQLite’ın varisi gibi davranma tavrından rahatsızlığımı dile getirdim ve bu yüzden birkaç yıl önce yazılımlarını hiç denememeye karar vermiştim.
  Ama SQL Server dışında da hızlı ve ucuz otomatik yenilenen materialized view sunarlarsa, sonunda kullanmak zorunda kalabilirim.