- Quack menyediakan komunikasi antar-instans DuckDB, memungkinkan konfigurasi klien-server dan penggunaan database yang sama oleh banyak penulis secara bersamaan
- Sambil mempertahankan arsitektur in-process, DuckDB menangani sinkronisasi status yang diperlukan saat beberapa proses memodifikasi file yang sama melalui protokol jarak jauh
- Quack adalah protokol request-response berbasis HTTP, menggunakan serialisasi
application/duckdb dan autentikasi token, dengan port default 9494
- Dalam benchmark, Quack mentransfer 60 juta baris dalam 4,94 detik, dan pada pengujian append kecil juga mencatat sekitar 5.434 tx/s dengan 8 thread
- Quack merencanakan integrasi DuckLake, server Catalog jarak jauh, instalasi·pemuatan otomatis, ekstensi protokol, dan protokol replikasi, dengan target rilis produksi pada periode DuckDB v2.0
Tujuan dan latar belakang Quack
- Quack adalah protokol jarak jauh yang memungkinkan instans DuckDB saling berkomunikasi, sehingga DuckDB dapat dijalankan dalam konfigurasi klien-server dan memungkinkan banyak penulis serentak menggunakan database yang sama
- Sejak 2019, DuckDB menekankan arsitektur in-process, dan pendekatan yang bekerja lewat panggilan API level rendah tanpa server atau protokol terpisah sangat cocok untuk pekerjaan data science interaktif seperti notebook Python dan penyediaan fitur SQL di dalam aplikasi
- Untuk memodifikasi file database DuckDB yang sama dari beberapa proses secara bersamaan, banyak status yang disimpan DuckDB di memori utama perlu disinkronkan antarproses
- Sebelumnya ada pendekatan alternatif seperti proses RPC terpisah, proyek yang menggunakan Arrow Flight SQL protocol, protokol milik MotherDuck, atau kombinasi PostgreSQL dan pg_duckdb seperti “EleDucken”
- Untuk memperluas DuckDB sebagai alat pengolahan data serbaguna, protokol klien-server dapat membuka kasus penggunaan baru selain kemampuan in-process
Cara menggunakan Quack
- Dalam Quack, dua atau lebih instans DuckDB saling berkomunikasi, dan DuckDB menjalankan peran klien dan server sekaligus
- Kedua instans dapat berada di komputer yang berbeda, lokasi jarak jauh, atau jendela terminal berbeda pada laptop yang sama
- Ekstensi Quack saat ini ada di repositori
core_nightly, dan bisa digunakan pada versi rilis saat ini DuckDB v1.5.2
- Pada instans DuckDB sisi server, setelah memasang dan memuat Quack, panggil
quack_serve, dan contoh menggunakan quack:localhost serta token = 'super_secret'
INSTALL quack FROM core_nightly;
LOAD quack;
CALL quack_serve(
'quack:localhost',
token = 'super_secret'
);
CREATE TABLE hello AS
FROM VALUES ('world') v(s);
- Pada instans DuckDB sisi klien, pasang dan muat Quack juga, atur token dengan
CREATE SECRET, lalu hubungkan instans jarak jauh dengan ATTACH 'quack:localhost' AS remote;
INSTALL quack FROM core_nightly;
LOAD quack;
CREATE SECRET (
TYPE quack,
TOKEN 'super_secret'
);
ATTACH 'quack:localhost' AS remote;
FROM remote.hello;
- Dengan konfigurasi ini, DuckDB #2 dapat mengambil nilai
world dari tabel jarak jauh hello
- Data juga bisa disalin dari instans lokal ke instans jarak jauh; dalam contoh, DuckDB #2 membuat tabel
remote.hello2, lalu DuckDB #1 memeriksanya dengan FROM hello2;
- Untuk kueri kompleks atau dataset besar, fungsi
query yang mengirim kueri apa adanya ke sisi jarak jauh memberi kontrol yang lebih baik atas pekerjaan mana yang dijalankan dari jarak jauh
FROM remote.query(
'SELECT s FROM hello'
);
Desain protokol
-
Berbasis HTTP
- Quack dibangun langsung di atas HTTP, yang secara praktis telah menjadi lapisan protokol standar di atas TCP dan lapisan di bawahnya
- Stack HTTP telah dioptimalkan secara efisien untuk pengiriman aliran pesan, dan bila diimplementasikan dengan benar, overhead-nya rendah
- Cara menangani HTTP sudah dikenal luas dalam area seperti load balancing, autentikasi, firewall, dan deteksi intrusi
- Karena menggunakan HTTP, rilis DuckDB-Wasm juga dapat menggunakan Quack secara native
- DuckDB yang berjalan di browser dapat terhubung langsung ke instans DuckDB yang berjalan di server EC2 melalui Quack
-
Pola request-response
- Interaksi Quack selalu berjalan dengan pola request-response yang dipimpin klien
- Pesan mencakup permintaan koneksi untuk autentikasi token, permintaan eksekusi kueri, pengembalian bagian pertama respons, dan pesan fetch lanjutan untuk mengambil hasil besar
- Hasil besar dapat diambil secara paralel oleh beberapa thread
-
Serialisasi
- Request dan response dienkode dengan tipe MIME baru
application/duckdb
- Encoding ini memanfaatkan primitive serialisasi internal DuckDB untuk struktur kompleks seperti tipe data dan result set
- Primitive yang sama juga telah digunakan selama bertahun-tahun pada file WAL DuckDB, dan telah banyak dioptimalkan serta divalidasi
-
Enkripsi dan cara eksposur
- Saat server dimulai, Quack secara default membuat token autentikasi acak, dan klien harus menyediakannya
- Server Quack secara default hanya bind ke
localhost, tetapi perilaku ini bisa dioverride
- Secara default tidak menggunakan SSL, karena menambahkan infrastruktur dan dependensi tersebut hanya untuk komunikasi
localhost dianggap tidak tepat
- Tidak disarankan mengekspos endpoint DuckDB Quack langsung ke internet
- Jika Quack perlu diekspos ke web, sangat disarankan menggunakan endpoint HTTP umum seperti nginx, dan membiarkan proxy tersebut melakukan terminasi SSL dengan Let’s Encrypt atau sejenisnya
- Klien Quack mengasumsikan SSL aktif untuk koneksi non-lokal, dan perilaku ini bisa dioverride
- Pengaturan terkait tersedia di dokumentasi reverse proxy
-
Optimasi jumlah round-trip
- Quack dirancang untuk mengurangi jumlah round-trip protokol yang diperlukan oleh kueri
- Setelah terhubung, satu kueri dapat diproses dalam satu round-trip, sehingga menguntungkan pada lingkungan yang sensitif terhadap latensi
- Pengiriman respons besar juga dioptimalkan, dan tim DuckDB menilai Quack saat ini sebagai cara tercepat untuk mentransfer tabel melalui socket
- Hasil benchmark menunjukkan jutaan baris dapat dikirim dalam hitungan detik
-
Autentikasi dan otorisasi
- Quack merancang model autentikasi dan otorisasi sesuai filosofi ekstensibilitas DuckDB
- Tersedia metode autentikasi default dan otorisasi default tanpa batasan, tetapi keduanya dapat diganti dengan kode yang disediakan pengguna
- Saat server dimulai, server membuat token autentikasi acak, dan klien memberikan string autentikasi saat koneksi
- Server memanggil callback autentikasi, dan callback default membandingkan token dari klien dengan token yang dibuat server
- Callback autentikasi bisa diganti melalui pengaturan, sehingga dapat memakai lookup direktori LDAP, membaca file teks, atau logika arbitrer lainnya
- Fungsi otorisasi juga bisa diganti, dan fungsi default mengizinkan semua permintaan
- Fungsi otorisasi buatan pengguna dapat memeriksa tiap kueri yang ingin dijalankan klien, lalu menilainya dengan mengaitkannya ke string autentikasi yang sebelumnya digunakan
- Callback seperti ini bahkan dapat ditulis sebagai makro SQL biasa
-
Port default
- Server Quack secara default mendengarkan pada port
9494
- Angka
94 dipilih agar mudah diingat, merujuk pada tahun rilis Netscape Navigator, yaitu 1994
Benchmark
- Benchmark dijalankan pada mesin virtual AWS yang menjalankan Ubuntu on Arm
- Tipe instans yang digunakan adalah m8g.2xlarge, dengan 8 vCPU, 32GB RAM, dan bandwidth jaringan “hingga 15Gbps”
- Ini mereproduksi skenario nyata di mana klien dan server berada di datacenter yang sama tetapi di mesin yang berbeda
- Kedua instans ditempatkan di availability zone yang sama, dan waktu ping rata-rata sekitar 0,280ms
-
Transfer besar
- Benchmark pertama mengukur pekerjaan transfer besar yang mengirim banyak baris melalui protokol database
- Pembandingnya adalah Quack, protokol PostgreSQL, dan protokol Arrow Flight SQL
- Arrow Flight disediakan lewat server GizmoSQL yang secara internal menggunakan DuckDB
- Pengiriman dilakukan dengan menaikkan jumlah baris dari tabel TPC-H
lineitem, dan diukur hingga maksimum 60 juta baris
- 60 juta baris setara dengan 76GB dalam format CSV
- Tiap hasil dilaporkan sebagai median wall-clock time dari 5 kali eksekusi
- Hasil utamanya sebagai berikut
- 100k baris: DuckDB Quack
0.07 s, Arrow Flight 0.07 s, PostgreSQL 0.20 s
- 1M baris: DuckDB Quack
0.24 s, Arrow Flight 0.38 s, PostgreSQL 2.20 s
- 10M baris: DuckDB Quack
0.89 s, Arrow Flight 2.90 s, PostgreSQL 25.64 s
- 60M baris: DuckDB Quack
4.94 s, Arrow Flight 17.40 s, PostgreSQL 158.37 s
- Quack mentransfer 60 juta baris dalam kurang dari 5 detik, menunjukkan performa kuat untuk pengiriman result set besar
- Bahkan Arrow Flight SQL yang berorientasi tujuan juga tidak menyamai Quack pada hasil ini, dan protokol berbasis baris PostgreSQL secara umum kurang unggul
- Klien PostgreSQL standar tidak memparalelkan pembacaan di beberapa thread, tetapi Quack dan Arrow dapat melakukannya
- Klien PostgreSQL milik DuckDB juga dapat melakukan pembacaan paralel pada beberapa kasus
-
Penulisan kecil
- Benchmark kedua mengukur pekerjaan append kecil
- Ini merepresentasikan situasi sentralisasi penulisan kecil, seperti konfigurasi yang mengumpulkan data observabilitas ke instans DuckDB pusat
- Ini adalah pengujian yang tidak menguntungkan bagi protokol yang memerlukan beberapa round-trip klien-server untuk menyelesaikan satu transaksi
- Dibuat tabel kosong dengan struktur yang sama seperti TPC-H
lineitem, lalu nilai acak dimasukkan satu baris per INSERT, masing-masing dalam transaksi terpisah
- Pengujian dijalankan selama 5 detik sambil menambah jumlah thread paralel, lalu eksperimen diulang 5 kali dan median transaksi per detik dilaporkan
- Hasil utamanya sebagai berikut
- 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 unggul atas PostgreSQL hingga 8 thread paralel, dengan throughput transaksi maksimum sekitar 5.500 tx/s
- Di atas itu, sistem mencapai batas DuckDB saat ini untuk jumlah insert serentak per detik pada tabel yang sama
- PostgreSQL melakukan scaling lebih baik di area ini, dan tim DuckDB melihatnya sebagai area yang akan ditinjau dalam waktu dekat
- Arrow Flight, sesuai dugaan, tidak tampil baik dan mencatat performa sekitar setengah dari PostgreSQL
- Skrip benchmark telah dipublikasikan
Kasus penggunaan dan maknanya bagi DuckDB
- Quack memungkinkan penggunaan DuckDB multipemain, di mana beberapa proses independen dapat memodifikasi isi tabel yang sama secara paralel, baik secara lokal maupun jarak jauh
- Sebagian kemampuan ini juga dimungkinkan oleh DuckLake, tetapi Quack membuatnya lebih sederhana dan menawarkan performa yang jauh lebih tinggi
- Ini memperluas cakupan penggunaan DuckDB pada kasus di mana status terpusat lebih penting daripada kueri lokal berlatensi sangat rendah
- Meluasnya data lake sudah menunjukkan bahwa data tidak selalu berada di lokal, dan Quack menjadi fitur yang sejalan dengan arah tersebut
- Quack akan diintegrasikan ke DuckLake, sehingga DuckDB sendiri dapat menjadi server Catalog yang dapat diakses dari jarak jauh
- Integrasi ini dapat membuka fitur baru seperti data inlining
- Pertanyaan tambahan tersedia di FAQ Quack
- DuckDB terus bergerak melampaui ceruk awalnya sebagai database in-process untuk analitik interaktif, menuju komponen inti arsitektur data modern
Mengapa tidak menggunakan Arrow Flight SQL
- Proyek terkait seperti Arrow dan ADBC bernilai sebagai API pertukaran untuk mengurangi friksi pertukaran data antarsistem, mirip ODBC dan JDBC
- Namun, penggunaan format pertukaran seperti Arrow di dalam internal DuckDB dipertimbangkan dengan hati-hati
- Struktur internal hasil perantara kueri DuckDB dalam beberapa hal mirip dengan Arrow, tetapi dalam hal lain cukup berbeda
- Agar dapat terus berinovasi dalam sistem data, mereka menilai tidak boleh dibatasi oleh format yang dikendalikan pihak luar, sehingga Quack menggunakan serialisasinya sendiri
- Dengan serialisasi sendiri, saat diperlukan tipe data baru atau pesan protokol baru, semuanya dapat langsung dirilis
- Arrow Flight SQL memiliki desain di mana setiap kueri memerlukan setidaknya dua round-trip protokol, yaitu
CommandStatementQuery dan DoGet
- Pendekatan ini tidak ideal untuk pekerjaan update kecil, terutama pada lingkungan dengan latensi lebih tinggi
- Quack dirancang agar kueri kecil dapat menjalankan eksekusi kueri dan fetch hasil dalam satu round-trip
Rencana ke depan
- Quack akan diintegrasikan ke DuckLake sehingga server DuckDB jarak jauh dapat digunakan sebagai DuckLake catalog
- Integrasi ini diperkirakan akan sangat meningkatkan performa, terutama pada inlining
- Dalam beberapa bulan ke depan, Quack akan terus disempurnakan, dengan rencana merilis versi produksi pertama bersamaan dengan DuckDB v2.0 yang dijadwalkan pada musim gugur tahun ini
- Ada rencana agar ekstensi Quack dapat terpasang dan termuat otomatis saat diperlukan
- Dengan parser baru, sintaks untuk berinteraksi dengan database SQL jarak jauh dari DuckDB juga akan ditingkatkan
- Dari sisi inti DuckDB, ada rencana untuk secara signifikan meningkatkan jumlah transaksi per detik, sehingga transaksi dapat terus diskalakan jauh melampaui 8 thread paralel
- Selain autentikasi dan otorisasi, juga sedang dipertimbangkan untuk mengizinkan ekstensi protokol Quack, sehingga ekstensi DuckDB dapat menambahkan pesan protokol baru dan kode penanganannya
- Menambahkan protokol replikasi di atas Quack juga sedang dipertimbangkan, agar perubahan pada instans DuckDB dapat direplikasi ke server lain dan klaster replika baca bisa dibentuk
- Quack dan pengenalan awalnya juga dijadwalkan dibahas pada konferensi komunitas 24 Juni DuckCon #7
- Tersedia juga halaman terpisah untuk proyek Quack
1 komentar
Komentar Hacker News
Minggu lalu aku sedang berharap ada sesuatu seperti ini, timing-nya pas sekali
Aku sedang mengalirkan nilai sensor ke DuckDB lewat server Deno, tapi tidak bisa memeriksa datanya dengan
duckdb -uitanpa mematikan serverAku tidak ingin menambahkan fitur ke server hanya untuk melihat isi DB, jadi rencananya mau dibiarkan dulu, tetapi ini menyelesaikan masalah itu dan beberapa masalah serupa yang selama ini kuhadapi dengan DuckDB dengan sangat rapi
DuckDB adalah teknologi favoritku di 2025/26, dan sudah masuk cukup dalam ke berbagai workflow seperti pekerjaan LLM, penyimpanan data, analisis, pipeline data, dan lain-lain
Aku sangat tertarik, tetapi sampai sekarang belum bisa memasukkan DuckDB secara alami ke cara pemecahan masalahku, jadi aku juga belum benar-benar tahu use case apa yang cocok dipetakan ke sana
Keren. Aku sedang melihat apakah DuckDB bisa dipakai di framework aplikasi internal perusahaan, dan ini menyelesaikan masalah “lalu bagaimana scale-out horizontalnya”
Salut untuk tim DuckDB, dan aku juga suka nama protokolnya, Quack
Aku sedang mengerjakan proyek open source yang menyimpan dan mengueri data observabilitas, yaitu metrik, log, dan trace, ke Parquet, dan meskipun aku sangat setuju soal pentingnya memakai format penyimpanan dan katalog terbuka, aku frustrasi dengan usability Apache Iceberg
Setelah melihat ini, DuckLake jadi terasa jauh lebih menarik untuk use case-ku, dan aku penasaran ke mana arahnya nanti
https://github.com/smithclay/duckdb-otlp
DuckDB memang bagus, tapi aku tidak yakin ia sebenarnya ingin menjadi apa
Cara pemakaiannya terus bertambah, dan tidak mudah melihat sekilas mana yang paling tepat
Upaya ini cukup konsisten, dan dalam satu sisi mengembalikannya ke model penggunaan yang familier, yaitu database relasional klien-server tradisional
DBMS relasional sejak awal memang sistem konkurensi multi-pengguna, dan DuckDB adalah engine lokal yang sangat cepat dengan beragam use case karena bisa di-embed ke sistem lain
Ini mirip seperti bertanya SQLite ingin jadi apa. Ia ada di ponsel, browser, aplikasi desktop, perangkat IoT, dan orang-orang sudah memperluasnya ke banyak arah. Bedanya, di sini yang melakukannya adalah first party, bukan third party, dan menurutku ini langkah yang sangat mudah dipahami
Aplikasi memantau aset di S3 dan mengambilnya saat etag berubah
Mudah mendapatkan performa seperti BigQuery atau ClickHouse tanpa harus mengoperasikan infrastrukturnya sendiri atau membayar biayanya
Memang tidak sempurna untuk semua kasus, tetapi bisa menangani jauh lebih banyak daripada yang diduga
Sekarang engine-nya sendiri tidak selalu jadi titik sakit; yang bermasalah justru sekelilingnya. DB live, path S3, file Parquet, kredensial, eksekusi yang dapat diulang, ekspor, validasi, dan momen ketika skrip sekali pakai diam-diam berubah menjadi infrastruktur
Quack merapikan bagian remote/server, tetapi arus besarnya menurutku adalah DuckDB sedang menjadi lapisan SQL di dalam tool, bukan tool untuk end user
Mereka tidak menjelaskan apa itu “penulis bersamaan”
Kelihatannya hanya menserialkan penulisan di sisi server
Aku tidak melihat alasan fitur ini tiba-tiba menserialkan semua penulisan
Ini tampak berguna untuk dataset analitik internal kecil yang ingin diletakkan di server tim bersama
Untuk homelab pun cukup layak untuk dilirik
Keunggulan besar protokol server ini adalah bisa berbagi server dengan memori besar dan memanfaatkan cache bersama untuk data terbaru
Aku punya aplikasi C++ dan selama berjalan semua data ada di memori
Di antara sesi, data disimpan ke disk dalam bentuk XML dan ini bekerja baik, tetapi secara ketat hanya untuk satu pengguna, dan beberapa pelanggan ingin menggeneralisasikannya agar banyak pengguna bisa membaca dan menulis secara bersamaan
Kebutuhan performanya rendah, mungkin hanya 2–3 orang yang memperbarui beberapa ribu entri secara bersamaan. Dalam kasus seperti ini, apakah DuckDB + Quack pilihan yang bagus? Atau ada opsi yang lebih baik? Aku juga melihat SQLite, tetapi kupahami ia tidak berjalan sebagai klien-server
Rasanya sulit menemukan pilihan yang bagus untuk database multi-pengguna tanpa meng-host sesuatu di sisi server dengan satu cara atau lainnya
Tentu saja ini mungkin, seperti beberapa game yang membuat klien-server multiplayer sendiri, tetapi jujur saja meng-host Postgres atau SQLite itu luar biasa murah dan mudah, dan yang paling penting, itu pendekatan standar untuk masalah ini
Luar biasa. Aku sedang membuat aplikasi spreadsheet kolumnar seperti Excel dengan DuckDB, tetapi harus membangun ulang “klien”-nya lewat lapisan HTTP tradisional
Pertanyaan “DuckDB ingin menjadi apa” terus muncul, tetapi menurutku jawabannya sudah jelas
Ia ingin menjadi SQLite untuk analitik. Bisa di-embed, tidak perlu konfigurasi, dan berjalan di mana saja
Quack hanya bagian yang memperluas “di mana saja” itu hingga mencakup remote
Untuk pertanyaan “Apakah DuckDB dengan Quack bisa dipakai sebagai database katalog DuckLake?”, tertulis “belum, tapi sedang dikerjakan!”
Ini terlihat seperti use case yang niche, tetapi justru inilah yang paling menarik bagiku
Lakehouse kami memakai DuckLake dan menggunakan Postgres sebagai katalog, tetapi katalog DuckDB / Quack sepertinya bisa menjadi alternatif yang sangat bagus
Alasannya ada beberapa. Pertama, tidak ada ketidakcocokan tipe dalam pemrosesan inline. Jika memakai katalog non-DuckDB, banyak tipe yang tidak bisa dipetakan 1:1 sehingga ada overhead tambahan saat menangani tipe data tersebut
Kedua, di atas katalog itu kita bisa langsung mendapatkan performa analitik DuckDB dan sekarang juga performa transaksionalnya. DuckDB yang membaca DuckDB memang lebih cepat daripada scanner Postgres/SQLite kami
Ketiga, tidak ada round-trip untuk retry. Seluruh logika retry bisa dijalankan dengan mudah(tm) di sisi server DuckDB. Saat ini retry semacam ini menyebabkan banyak round-trip ke Postgres dan menjadi bottleneck performa pada workload yang contention-nya tinggi
Sebagai catatan, aku pengembang duckdb/ducklake
Sepertinya sudah bisa diuji dalam beberapa hari ke depan