- Quack, DuckDB örnekleri arasında iletişim sağlayarak istemci-sunucu yapılandırmasını ve birden fazla eşzamanlı yazanın aynı veritabanını kullanmasını mümkün kılar
- DuckDB, in-process mimarisini korurken, birden fazla sürecin aynı dosyayı değiştirmesi gerektiğinde gereken durum senkronizasyonunu uzak protokol üzerinden işler
- Quack, HTTP tabanlı bir istek-yanıt protokolüdür;
application/duckdb serileştirmesi ve token kimlik doğrulaması kullanır, varsayılan portu 9494'tür
- Karşılaştırmalarda Quack, 60 milyon satırı 4.94 saniyede aktardı; küçük append testinde de 8 thread ile yaklaşık 5,434 tx/s kaydetti
- Quack; DuckLake entegrasyonu, uzak Catalog sunucusu, otomatik kurulum-yükleme, protokol genişletmeleri ve replikasyon protokolü planlıyor; DuckDB v2.0 döneminde production sürümünü hedefliyor
Quack'in amacı ve arka planı
- Quack, DuckDB örneklerinin birbiriyle iletişim kurmasını sağlayan bir uzak protokoldür; DuckDB'yi istemci-sunucu yapılandırmasında çalıştırmayı ve birden fazla eşzamanlı yazanın aynı veritabanını kullanmasını mümkün kılar
- DuckDB, 2019'dan beri in-process mimariyi vurguluyor; ayrı bir sunucu ya da protokol olmadan düşük seviyeli API çağrılarıyla çalışan bu yaklaşım, Python notebook'ları gibi etkileşimli veri bilimi işleriyle uygulama içi SQL yetenekleri sunmaya çok uygundu
- Aynı DuckDB veritabanı dosyasını birden fazla sürecin aynı anda değiştirebilmesi için, DuckDB'nin ana bellekte tuttuğu çok sayıda durumun süreçler arasında senkronize edilmesi gerekir
- Daha önce ayrı bir RPC süreci, Arrow Flight SQL protocol kullanan projeler, MotherDuck'ın kendi protokolü ya da PostgreSQL ile pg_duckdb'yi birleştiren “EleDucken” gibi dolaylı çözümler vardı
- DuckDB'yi genel amaçlı veri işleme aracı olarak genişletmek için, in-process yeteneklere ek olarak istemci-sunucu protokolü yeni kullanım senaryolarının önünü açabilir
Quack nasıl kullanılır
- Quack'te iki veya daha fazla DuckDB örneği birbiriyle iletişim kurar ve DuckDB hem istemci hem sunucu rolünü üstlenir
- İki örnek farklı bilgisayarlarda, uzak konumlarda veya aynı dizüstü bilgisayardaki farklı terminal pencerelerinde olabilir
- Quack uzantısı şu anda
core_nightly deposunda yer alıyor ve mevcut sürüm olan DuckDB v1.5.2 ile kullanılabiliyor
- Sunucu tarafındaki DuckDB örneğinde Quack kurulup yüklendikten sonra
quack_serve çağrılır; örnekte quack:localhost ve token = 'super_secret' kullanılıyor
INSTALL quack FROM core_nightly;
LOAD quack;
CALL quack_serve(
'quack:localhost',
token = 'super_secret'
);
CREATE TABLE hello AS
FROM VALUES ('world') v(s);
- İstemci tarafındaki DuckDB örneğinde de Quack kurulup yüklenir,
CREATE SECRET ile token ayarlanır ve ardından ATTACH 'quack:localhost' AS remote; ile uzak örneğe bağlanılır
INSTALL quack FROM core_nightly;
LOAD quack;
CREATE SECRET (
TYPE quack,
TOKEN 'super_secret'
);
ATTACH 'quack:localhost' AS remote;
FROM remote.hello;
- Bu yapılandırmayla DuckDB #2, uzak
hello tablosundaki world değerini sorgulayabilir
- Yerel örnekten uzak örneğe veri kopyalamak da mümkündür; örnekte DuckDB #2'de
remote.hello2 tablosu oluşturulur ve DuckDB #1'de FROM hello2; ile doğrulanır
- Karmaşık sorgularda veya büyük veri kümelerinde, sorguyu olduğu gibi uzak tarafa gönderen
query fonksiyonu ile hangi işin uzakta çalışacağını daha iyi kontrol etmek mümkündür
FROM remote.query(
'SELECT s FROM hello'
);
Protokol tasarımı
-
HTTP tabanlı
- Quack doğrudan HTTP üzerine kuruldu; HTTP, TCP ve alt katmanların üzerinde fiilî standart protokol katmanı hâline gelmiş durumda
- HTTP yığını, mesaj akışlarının taşınmasına uygun şekilde verimli biçimde optimize edilmiştir ve doğru uygulandığında ek yükü düşüktür
- Yük dengeleme, kimlik doğrulama, güvenlik duvarı ve izinsiz giriş tespiti gibi alanlarda HTTP ile nasıl çalışılacağı yaygın olarak bilinir
- HTTP kullanıldığı için DuckDB-Wasm dağıtımı da Quack'i yerel olarak kullanabilir
- Tarayıcıda çalışan DuckDB, Quack üzerinden EC2 sunucusunda çalışan bir DuckDB örneğine doğrudan bağlanabilir
-
İstek-yanıt deseni
- Quack etkileşimleri her zaman istemcinin yönettiği istek-yanıt deseni ile çalışır
- Mesajlar; token kimlik doğrulaması için bağlantı isteği, sorgu çalıştırma isteği, yanıtın ilk bölümünün döndürülmesi ve büyük sonuçları almak için sonraki fetch mesajları gibi bileşenler içerir
- Büyük sonuçlar birden fazla thread üzerinden paralel olarak getirilebilir
-
Serileştirme
- İstekler ve yanıtlar, yeni MIME türü
application/duckdb ile kodlanır
- Bu kodlama, veri türleri ve sonuç kümeleri gibi karmaşık yapılar için DuckDB'nin iç serileştirme primitive'lerinden yararlanır
- Aynı primitive'ler yıllardır DuckDB'nin WAL dosyalarında da kullanılıyor ve ciddi ölçüde optimize edilip doğrulandı
-
Şifreleme ve açığa çıkarma biçimi
- Quack, sunucu başlatılırken varsayılan olarak rastgele bir kimlik doğrulama tokenı üretir ve istemcinin bunu sağlaması gerekir
- Quack sunucusu varsayılan olarak yalnızca
localhost'a bind olur; bu davranış değiştirilebilir
- Varsayılan olarak SSL kullanmaz; yalnızca
localhost iletişimi için bu altyapı ve bağımlılıkları eklemenin uygun olmadığı düşünülür
- DuckDB Quack endpoint'ini doğrudan internete açmak önerilmez
- Quack'i web'e açmanız gerekiyorsa, nginx gibi standart bir HTTP endpoint'i kullanmanız ve bu proxy'nin Let’s Encrypt benzeri bir çözümle SSL sonlandırması yapması güçlü biçimde tavsiye edilir
- Quack istemcisi, yerel olmayan bağlantılarda SSL'in etkin olduğunu varsayar; bu davranış değiştirilebilir
- İlgili ayarlar reverse proxy belgelerinde bulunabilir
-
Gidiş-dönüş sayısını optimize etme
- Quack, sorgular için gereken protokol gidiş-dönüş sayısını azaltacak şekilde tasarlanmıştır
- Bağlantı kurulduktan sonra tek bir sorgu, tek gidiş-dönüşle işlenebilir; bu da gecikmeye duyarlı ortamlarda avantaj sağlar
- Büyük yanıtların aktarımı da optimize edilmiştir ve DuckDB ekibi Quack'in şu anda socket üzerinden tablo aktarmanın en hızlı yolu olduğunu düşünüyor
- Karşılaştırmalar, milyonlarca satırın birkaç saniye içinde aktarılabildiğini gösteriyor
-
Kimlik doğrulama ve yetkilendirme
- Quack, DuckDB'nin genişletilebilirlik felsefesine uygun bir kimlik doğrulama ve yetkilendirme modeliyle tasarlandı
- Varsayılan bir kimlik doğrulama yöntemi ve sınırsız varsayılan yetkilendirme sunar; ancak ikisi de kullanıcı tarafından sağlanan kodla değiştirilebilir
- Sunucu başlatılırken rastgele bir kimlik doğrulama tokenı üretilir ve istemci bağlantı sırasında bir kimlik doğrulama dizesi sağlar
- Sunucu bir doğrulama callback'i çağırır; varsayılan callback, istemcinin sağladığı token ile sunucunun ürettiği tokenı karşılaştırır
- Doğrulama callback'i ayarlarla değiştirilebilir; böylece LDAP dizini sorgulama, metin dosyası okuma veya keyfî mantık kullanılabilir
- Yetkilendirme fonksiyonu da değiştirilebilir; varsayılan fonksiyon tüm istekleri kabul eder
- Kullanıcı tanımlı yetkilendirme fonksiyonu, istemcinin çalıştırmak istediği her sorguyu inceleyip daha önce kullanılan kimlik doğrulama dizesiyle ilişkilendirerek karar verebilir
- Bu callback'ler normal SQL makroları olarak da yazılabilir
-
Varsayılan port
- Quack sunucusu varsayılan olarak
9494 portunu dinler
94 sayısı, Netscape Navigator'ın çıktığı yıl olan 1994'ü kolay hatırlatması için seçilmiştir
Karşılaştırmalar
- Karşılaştırmalar, Ubuntu on Arm çalıştıran AWS sanal makinelerinde yapıldı
- Örnek türü m8g.2xlarge; 8 vCPU, 32GB RAM ve “15Gbps'e kadar” ağ bant genişliğine sahipti
- Amaç, istemci ile sunucunun aynı veri merkezinde fakat farklı makinelerde olduğu gerçekçi bir senaryoyu yeniden üretmekti
- İki örnek aynı availability zone içine yerleştirildi ve ortalama ping süresi yaklaşık 0.280ms oldu
-
Büyük hacimli aktarım
- İlk benchmark, veritabanı protokolü üzerinden çok sayıda satır göndermeye yönelik büyük hacimli aktarım işini ölçüyor
- Karşılaştırılanlar Quack, PostgreSQL protokolü ve Arrow Flight SQL protokolü
- Arrow Flight, iç tarafta DuckDB kullanan GizmoSQL sunucusu üzerinden sağlandı
- TPC-H
lineitem tablosunda satır sayısı kademeli artırılarak aktarım yapıldı ve en fazla 60 milyon satır ölçüldü
- 60 milyon satır, CSV biçiminde 76GB'a karşılık geliyor
- Her sonuç, 5 çalıştırmanın medyan duvar saati süresi olarak raporlandı
- Başlıca sonuçlar şöyle
- 100k satır: DuckDB Quack
0.07 s, Arrow Flight 0.07 s, PostgreSQL 0.20 s
- 1M satır: DuckDB Quack
0.24 s, Arrow Flight 0.38 s, PostgreSQL 2.20 s
- 10M satır: DuckDB Quack
0.89 s, Arrow Flight 2.90 s, PostgreSQL 25.64 s
- 60M satır: DuckDB Quack
4.94 s, Arrow Flight 17.40 s, PostgreSQL 158.37 s
- Quack, 60 milyon satırı 5 saniyenin altında aktararak büyük sonuç kümelerinin iletiminde güçlü performans gösterdi
- Amaca yönelik Arrow Flight SQL bile bu sonuçlarda Quack'e yetişemedi; PostgreSQL'in satır tabanlı protokolü ise genel olarak dezavantajlı kaldı
- Standart PostgreSQL istemcisi, okumayı birden fazla thread'de paralelleştirmez; Quack ve Arrow ise bunu yapabilir
- DuckDB'nin PostgreSQL client uzantısı da bazı durumlarda paralel okuma yapabilir
-
Küçük yazmalar
- İkinci benchmark, küçük append işlemlerini ölçüyor
- Bu, gözlemlenebilirlik verilerini merkezi bir DuckDB örneğinde toplama gibi, küçük yazmaların merkezileştirildiği senaryolara karşılık geliyor
- Tek bir transaction'ı tamamlamak için birden fazla istemci-sunucu gidiş-dönüşü gerektiren protokoller için dezavantajlı bir test
- TPC-H
lineitem ile aynı yapıda boş bir tablo oluşturulup, rastgele değerler tek satır hâlinde ve her biri ayrı bir INSERT transaction'ı olarak eklendi
- Paralel thread sayısı artırılarak test 5 saniye boyunca çalıştırıldı; deney 5 kez tekrarlandı ve medyan transaction/saniye değeri raporlandı
- Başlıca sonuçlar şöyle
- 1 thread: DuckDB Quack
1,038 tx/s, Arrow Flight 469 tx/s, PostgreSQL 839 tx/s
- 2 thread: DuckDB Quack
1,956 tx/s, Arrow Flight 799 tx/s, PostgreSQL 1,094 tx/s
- 4 thread: DuckDB Quack
3,504 tx/s, Arrow Flight 1,224 tx/s, PostgreSQL 2,180 tx/s
- 8 thread: DuckDB Quack
5,434 tx/s, Arrow Flight 1,358 tx/s, PostgreSQL 4,320 tx/s
- Quack, 8 paralel thread'e kadar PostgreSQL'i geçti ve en yüksek yaklaşık 5,500 tx/s transaction throughput'u gösterdi
- Bunun ötesinde, aynı tabloya eşzamanlı ekleme sayısında DuckDB'nin mevcut iç sınırlarına ulaşılıyor
- PostgreSQL bu alanda daha iyi ölçekleniyor ve DuckDB ekibi bunu yakın gelecekte ele almayı planlıyor
- Arrow Flight beklenildiği gibi iyi sonuç vermedi ve PostgreSQL'in yaklaşık yarısı düzeyinde kaldı
- Benchmark script'leri açık olarak yayımlandı
Kullanım senaryoları ve DuckDB için anlamı
- Quack, birden fazla bağımsız sürecin yerelde veya uzaktan aynı tablo içeriğini paralel biçimde değiştirebildiği çok oyunculu DuckDB kullanımını mümkün kılar
- Bunun bazı yönleri DuckLake ile de yapılabiliyordu; ancak Quack bunu daha basit hâle getiriyor ve çok daha yüksek performans sunuyor
- Merkezi durumun, aşırı yakın yerel sorgulardan daha önemli olduğu kullanım senaryolarında DuckDB'nin kullanılabileceği alan genişliyor
- Veri göllerinin yaygınlaşması, verinin her zaman yerelde olmadığını zaten gösterdi; Quack de bu yöne uygun bir özellik olarak konumlanıyor
- Quack, DuckLake'e entegre edilecek ve DuckDB'nin uzak erişilebilir bir Catalog sunucusu olmasını sağlayacak
- Bu entegrasyon, veri inlining gibi yeni özelliklerin önünü açabilir
- Ek sorular için Quack SSS sayfasına bakılabilir
- DuckDB, etkileşimli analiz için in-process veritabanı olan ilk nişinden çıkarak modern veri mimarisinin temel bileşenlerinden biri olmaya doğru ilerliyor
Neden Arrow Flight SQL kullanılmadı?
- Arrow ve ADBC gibi ilgili projeler, ODBC ve JDBC benzeri şekilde sistemler arası veri alışverişindeki sürtünmeyi azaltan değişim API'leri olarak değerlidir
- Ancak DuckDB içinde Arrow gibi bir değişim biçimini kullanma konusunda temkinli davranılıyor
- DuckDB'nin sorgu ara sonuçlarının iç yapısı bazı yönlerden Arrow'a yakın olsa da, diğer yönlerden oldukça farklıdır
- Veri sistemlerinde yenilik yapmayı sürdürmek için dışarıdan kontrol edilen biçimlerle sınırlı kalınmaması gerektiği düşünülüyor; bu yüzden Quack kendi serileştirmesini kullanıyor
- Kendi serileştirmesini kullanmak, yeni veri türleri veya yeni protokol mesajları gerektiğinde bunların hemen dağıtılabilmesini sağlar
- Arrow Flight SQL'in tasarımı, her sorgunun en az iki protokol gidiş-dönüşü gerektirmesine yol açıyor:
CommandStatementQuery ve DoGet
- Bu yaklaşım, özellikle gecikmenin daha yüksek olduğu ortamlardaki küçük güncelleme işleri için ideal değil
- Quack, küçük sorgularda sorgu yürütme ile sonuç fetch işlemini tek gidiş-dönüşte yapabilecek şekilde tasarlandı
Gelecek planları
- Quack, DuckLake'e entegre edilerek uzak DuckDB sunucularının DuckLake catalog olarak kullanılabilmesini sağlayacak
- Özellikle inlining tarafında bu entegrasyonun performansı ciddi biçimde artırması bekleniyor
- Önümüzdeki birkaç ay içinde Quack'i olgunlaştırıp, bu sonbaharda planlanan DuckDB v2.0 ile birlikte ilk production sürümünü yayımlamayı planlıyorlar
- Gerektiğinde Quack uzantısı için otomatik kurulum ve otomatik yükleme sağlanması planlanıyor
- Yeni parser kullanılarak DuckDB içinde uzak SQL veritabanlarıyla etkileşim sözdiziminin iyileştirilmesi de planlanıyor
- DuckDB çekirdeği tarafında, transaction/saniye değerinin ciddi biçimde artırılarak 8 paralel thread'in çok ötesine ölçeklenmesi hedefleniyor
- Kimlik doğrulama ve yetkilendirmenin ötesinde, DuckDB uzantılarının yeni protokol mesajları ve işleme kodu ekleyebilmesine olanak tanıyan Quack protokol genişletmeleri de değerlendiriliyor
- Quack üzerine bir replikasyon protokolü eklenerek DuckDB örneklerindeki değişikliklerin başka sunuculara kopyalanması ve read replica kümeleri kurulması da düşünülüyor
- Quack ve ilk kullanım örnekleri, 24 Haziran'daki topluluk konferansı DuckCon #7 kapsamında da ele alınacak
- Ayrıca ayrı bir Quack project sayfası da bulunuyor
1 yorum
Hacker News yorumları
Geçen hafta tam da böyle bir şey olsa ne iyi olurdu; zamanlaması cuk oturmuş
Sensör değerlerini bir Deno sunucusundan DuckDB'ye akıtıyordum ama sunucuyu kapatmadan
duckdb -uiile veriyi inceleyemiyordumVeritabanının içeriğini görmek için sunucuya ayrıca özellik eklemek istemediğimden bir süre böyle idare edecektim, ama bu hem o sorunu hem de DuckDB ile yaşadığım benzer sorunları temiz biçimde çözüyor
DuckDB, 2025/26 dönemindeki en sevdiğim teknoloji; LLM çalışmaları, veri depolama, analiz, veri hattı gibi birçok iş akışına derinlemesine girmiş durumda
Çok ilgimi çekiyor ama DuckDB'yi sorun çözme yaklaşımıma henüz doğal şekilde yerleştiremedim; hangi kullanım senaryolarına oturtabileceğimi de pek kestiremiyorum
Harika. Şirket içi uygulama çatımızda DuckDB kullanmayı düşünüyordum; bu da “peki yatay ölçeklemeyi nasıl yapacağız” sorununu çözmüş oldu
DuckDB ekibini alkışlıyorum, ayrıca protokol adının Quack olması da hoşuma gitti
Gözlemlenebilirlik verilerini, yani metrikleri, logları ve trace'leri Parquet içinde saklayıp sorgulayan açık kaynaklı bir proje üzerinde çalışıyordum; açık depolama biçimleri ve kataloglar kullanmak isteme fikrine güçlü biçimde katılıyorum ama Apache Iceberg'ün kullanılabilirliği beni zorluyordu
Bunu görünce DuckLake benim kullanım senaryom için çok daha ilgi çekici hale geldi; nereye evrileceğini merakla bekliyorum
https://github.com/smithclay/duckdb-otlp
DuckDB güzel ama neye dönüşmek istediğini tam anlayamıyorum
Sürekli yeni kullanım biçimleri çıkıyor ve hangisinin doğru yaklaşım olduğunu bir bakışta görmek kolay değil
Bu girişim oldukça tutarlı; hatta onu geleneksel istemci-sunucu ilişkisel veritabanı gibi tanıdık bir kullanım modeline geri yaklaştıran bir yanı var
İlişkisel VTYS'ler zaten en başından çok kullanıcılı eşzamanlılık sistemleriydi; DuckDB ise başka sistemlere gömülebilen ve çok çeşitli kullanım senaryolarına sahip, son derece hızlı bir yerel motor
Bu, SQLite'a ne olmak istediğini sormaya benziyor. Telefonlarda, tarayıcılarda, masaüstü uygulamalarda, IoT cihazlarında yer alıyor ve insanlar onu farklı yönlere doğru genişletti. Buradaki fark, bunun üçüncü taraflarca değil birinci tarafça yapılıyor olması; bana gayet anlaşılır bir hamle gibi geliyor
Uygulama S3 üzerindeki varlıkları izliyor ve etag değiştiğinde dosyayı çekiyor
BigQuery ya da ClickHouse benzeri performansı, o altyapıyı bizzat işletmeden veya maliyetine katlanmadan elde etmek kolaylaşıyor
Her durum için mükemmel değil ama beklediğimden çok daha fazlasını kaldırıyor
Artık asıl sorun her zaman motorun kendisi değil; çevresindeki parçalar. Canlı VT, S3 yolları, Parquet dosyaları, kimlik bilgileri, tekrarlanabilir çalıştırmalar, dışa aktarma, doğrulama ve tek seferlik betiklerin sessizce altyapıya dönüştüğü anlar
Quack uzaktaki/sunucu tarafını daha temiz hale getiriyor ama daha büyük eğilim, DuckDB'nin son kullanıcı aracı olmaktan çok araçların içindeki SQL katmanı haline gelmesi gibi görünüyor
“Eşzamanlı yazarlar”ın ne olduğu açıklanmamış
Görünüşe göre yazmaları sunucu tarafında serileştiriyorlar
Bu özelliğin bir anda bütün yazmaları serileştirmesi için bir neden göremiyorum
Paylaşılan bir ekip sunucusuna koymak isteyeceğiniz küçük dahili analiz veri kümeleri için kullanışlı görünüyor
Homelab için de kesinlikle bakmaya değer
Bu sunucu protokolünün büyük avantajı, bol belleğe sahip bir sunucuyu paylaşabilmek ve yakın tarihli veriler için paylaşılan önbellekten yararlanabilmek
Bir C++ uygulamam var ve çalışırken her şey bellekte duruyor
Oturumlar arasında diske XML olarak kaydediyor ve iyi çalışıyor ama aslında tek kullanıcılık; bazı müşteriler bunun birden fazla kullanıcının aynı anda okuyup yazabildiği daha genel bir yapıya kavuşmasını istiyor
Performans gereksinimi düşük; aynı anda 2-3 kişinin birkaç bin kaydı güncellemesi düzeyinde. Böyle bir durumda DuckDB + Quack iyi bir seçim olur mu? Yoksa daha iyi bir alternatif var mı? SQLite'a da baktım ama benim anladığım kadarıyla istemci-sunucu şeklinde çalışmıyor
Eşzamanlı kullanıcıları işleyecek bir VT'yi sunucu tarafında bir şekilde barındırmadan kullanmak için iyi bir seçenek bulmanın zor olacağını düşünüyorum
Elbette, bazı oyunların çok oyunculu için doğrudan kendi istemci-sunucu yapısını kurması gibi, bu da yapılabilir; ama dürüst olmak gerekirse Postgres ya da SQLite barındırmak saçılacak kadar ucuz ve kolay, üstelik bu sorun için standart yaklaşım da bu
Mükemmel. DuckDB kullanarak Excel benzeri sütun odaklı bir hesap tablosu uygulaması geliştiriyordum ama “istemciyi” geleneksel bir HTTP katmanı üzerinden yeniden kurmam gerekmişti
“DuckDB ne olmak istiyor” sorusu sürekli dönüp duruyor ama bence yanıt zaten açık
Analitik için SQLite olmak istiyor. Gömülebilir, kurulum gerektirmez ve her yerde çalışır
Quack de sadece o “her yerde” kısmına uzak erişimi ekliyor
“Quack ile birlikte DuckDB'yi DuckLake'in katalog veritabanı olarak kullanabilir miyiz?” sorusuna “Henüz değil ama üzerinde çalışıyoruz!” denmiş
Niş bir kullanım senaryosu gibi görünüyor ama benim en çok ilgimi çeken kısım bu
Bizim lakehouse'umuz DuckLake kullanıyor ve katalog için Postgres kullanıyoruz; DuckDB / Quack kataloğu mükemmel bir alternatif olabilir gibi duruyor
Bunun birkaç nedeni var. Birincisi, satır içi işlemede tip uyumsuzluğu yok. DuckDB dışı bir katalog kullandığınızda birçok tip bire bir eşleşmiyor; bu da ilgili veri tipleriyle uğraşırken ek yük oluşturuyor
İkincisi, katalog üzerinde DuckDB'nin analitik performansını ve artık işlemsel performansını da aynen elde edebiliyorsunuz. DuckDB'nin DuckDB okuması, Postgres/SQLite tarayıcılarımıza göre düpedüz daha hızlı
Üçüncüsü, yeniden deneme için gidiş geliş yok. Tüm yeniden deneme mantığını DuckDB sunucu tarafında kolayca(tm) çalıştırabiliyoruz. Şu anda bu yeniden denemeler Postgres'e birden fazla gidiş geliş oluşturuyor ve çekişmenin yüksek olduğu iş yüklerinde performans darboğazına yol açıyor
Not: duckdb/ducklake geliştiricisiyim
Birkaç gün içinde test edilebilir hale gelecek