DuckDB 2.0 ve Quack: Gömülü veritabanı artık sunucu da olabiliyor

Hiç sunucusu olmayan veritabanı

DuckDB yazımızda anlattığımız gibi, DuckDB’nin bütün fikri sunucusuz olmaktı. SQLite gibi programının içinde çalışıyor, bir dosyayı açıyor, analizini yapıyor. Kurulacak servis, açılacak port yok.

Bu tasarımın bir bedeli vardı: Aynı veritabanı dosyasına aynı anda tek bir süreç yazabiliyordu. DuckDB çalışırken belleğinde çok fazla durum tutuyor ve iki ayrı sürecin bunu birbirine göre güncel tutması zor. Bu yüzden ekipler kendi çözümlerini kuruyordu: DuckDB’yi saran küçük bir RPC servisi, Arrow Flight SQL köprüleri ya da DuckDB’yi Postgres’in içine taşıyan eklentiler.

DuckDB ekibi sonunda bu işi kendisi yapmaya karar verdi. Adı Quack.

Quack nedir?

Quack, DuckDB’ye özel bir istemci-sunucu protokolü. Bir DuckDB süreci veritabanını sunar, diğerleri ağ üzerinden ona bağlanıp sorgu çalıştırır. İlk hâli Mayıs 2026’da bir eklenti olarak geldi. 21 Ekim’de çıkan DuckDB 2.0.0 ile cilalanmış hâli, çekirdekle birlikte gelen quack eklentisinde.

Kullanımı kısa. Sunucu tarafında:

CALL quack_serve('quack:localhost', token = 'gizli_anahtar');

İstemci tarafında:

ATTACH 'quack:sunucu.example.com' AS uzak (TOKEN 'gizli_anahtar');
CONNECT uzak;
SELECT count(*) FROM olaylar;

CONNECT ile oturumun tamamı uzaktaki sunucuya yönleniyor; sorgu orada çalışıyor, sonuç sana geliyor. DISCONNECT ile yerel veritabanına dönüyorsun. Komut satırında da -serve ve -connect seçenekleri var.

Neden HTTP?

Quack, HTTP üzerinde çalışıyor (varsayılan port 9494). Ekip bunu bilerek seçmiş: Yük dengeleme, kimlik doğrulama, güvenlik duvarı gibi konularda HTTP için hazır araçlar zaten var. Bir yan etkisi de güzel: DuckDB’nin tarayıcıda çalışan WebAssembly sürümü de Quack konuşabiliyor.

Veri, DuckDB’nin yıllardır kendi kayıt dosyasında (write-ahead log) kullandığı ikili formatla gidiyor. Protokol, bir sorgunun tek gidiş-dönüşte bitmesi için tasarlanmış. Büyük sonuçlar ayrı isteklerle, gerekirse paralel çekiliyor.

Ekibin kendi ölçümüne göre 60 milyon satırı aktarmak Quack ile yaklaşık 5 saniye, Arrow Flight ile 17, Postgres protokolüyle 158 saniye sürmüş. Sebep basit: Postgres protokolü satır satır gönderiyor, DuckDB ise sütun tabanlı veriyi toplu taşıyor.

Nerede dikkat etmeli?

• Güvenlik varsayılanları sade. Sunucu sadece kendi makinesini (localhost) dinliyor ve başlarken rastgele bir token üretiyor. Ama varsayılan yetkilendirme her sorguya izin veriyor. Kullanıcı bazlı kurallar istiyorsan kendin yazıyorsun.
• Doğrudan internete açma. Ekip, sunucuyu localhost’ta tutup önüne TLS’i karşılayan bir ters proxy (örneğin nginx) koymayı öneriyor.
• Küçük yazmalarda Postgres hâlâ önde. Aynı tabloya çok sayıda küçük yazmada performans sekiz iş parçacığından sonra artmıyor. Quack, DuckDB’yi bir Postgres yerine geçirmiyor; analiz veritabanına çok kişinin erişebilmesini sağlıyor.

2.0’da başka neler var?

• Yeni SQL ayrıştırıcısı (PEG parser) artık varsayılan. Hata mesajları hatanın yerini daha net gösteriyor ve eklentiler dile yeni söz dizimi ekleyebiliyor.
• Ajan modu: Komut satırını bir yapay zekâ ajanı kullandığında çıktı daha kısa tablolara dönüyor, hatalar JSON olarak geliyor.
• Tetikleyiciler (trigger) ve dosya okumada eşzamansız G/Ç geldi.
• Uyumluluk: 2.0 ile oluşturulan veritabanı dosyalarını eski sürümler açamıyor. Yükseltmeden önce geçiş rehberine bakmak gerekiyor. 2.0, en az Ekim 2027’ye kadar destekleniyor.

Düşün

• Bir aracın “tek iş, sunucusuz” kimliğini koruması mı, kullanıcıların istediği özellikleri eklemesi mi daha doğru?
• Ekibinde birden fazla kişinin aynı analiz verisine eriştiği bir durum var mı? Bugün bunu nasıl çözüyorsunuz?

Kendi cümlelerimizle yazılmış bir özettir, çeviri değildir. Tüm kaynaklar yukarıda.