On May 12, 2026, the DuckDB team published Quack, a new remote protocol that lets one DuckDB talk to another. The same binary acts as both client and server, so multiple separate processes — local or across machines — can modify tables concurrently without locking each other out. It ships today as an experimental extension, with a first production release planned alongside DuckDB v2.0 in fall 2026.
This closes a long-standing architectural gap. DuckDB was designed from day one as an in-process engine, the same bet as SQLite, and that choice won the data-science notebook and embedded-SQL markets. What it never had was an official answer for “multiple processes writing to the same data.” The team’s framing is unusually candid: they care deeply about user experience, and rather less about having the last word on architecture.
What Quack Is
Quack is built directly on HTTP, with the networking stack optimized around it. Messages use a new MIME type, application/duckdb, that reuses DuckDB’s internal serialization primitives — the same machinery behind its write-ahead log, described as battle-tested. The pattern is client-driven request-response: after connecting, a query needs a single round trip, with follow-up fetch messages for large results that can be parallelized across threads. DuckDB-Wasm speaks Quack natively, so a DuckDB running in a browser tab can connect to a DuckDB server on EC2. The default port is 9494 — a nod to 1994, the year Netscape Navigator shipped. On the server side you start it with CALL quack_serve and a token; on the client side you register a quack secret and ATTACH. The extension is MIT-licensed in the duckdb/duckdb-quack repository and auto-installs on first use.
Why Not Just Use Arrow Flight SQL
Two reasons. First, Flight SQL is an externally governed interchange format, and DuckDB did not want protocol evolution tied to someone else’s timetable. Second, Flight SQL mandates two round trips per query — a CommandStatementQuery followed by a DoGet — which hurts exactly the small, frequent transactions DuckDB users care about. The team also admits the demand was already visible: the community had been bolting on custom RPC layers, Arrow Flight SQL adapters, MotherDuck’s proprietary protocol, and “EleDucken” setups that put PostgreSQL in front via pg_duckdb.
The Numbers: One Round Trip vs. Two
Benchmarks ran on an AWS m8g.2xlarge (8 vCPUs, 32 GB RAM, roughly 15 Gbps network, 0.28 ms ping). Bulk transfer of the TPC-H lineitem table: 60 million rows in 4.94 seconds over Quack, 17.40 seconds over Arrow Flight SQL via GizmoSQL, and 158.37 seconds through PostgreSQL. At 10 million rows the split is 0.89 vs 2.90 vs 25.64 seconds; at 1 million, 0.24 vs 0.38 vs 2.20. For small single-row INSERT transactions (median of five runs), one thread sustains 1,038 tx/s on Quack vs 469 on Arrow and 839 on PostgreSQL, while eight threads reach 5,434 vs 1,358 vs 4,320. The team’s pitch line: “the fastest way to shove tables through a socket.” The honest footnote: beyond eight threads PostgreSQL scales better, capped by a DuckDB concurrent-insert limit that is already on the roadmap.
Security Model and Current Limits
The server generates a random auth token at startup and binds to localhost by default. There is no SSL out of the box; for public exposure the recommendation is a reverse proxy such as nginx with Let’s Encrypt. Both authentication and authorization are overridable — the token check can be replaced with custom code, and the authorization callback can even be written as a plain SQL macro, say to consult LDAP. Status-wise, the team is explicit that this is a pre-release, experimental extension: the repository’s Releases page is empty, and issues should go to GitHub. The Hacker News thread sits at 387 points and 83 comments. For teams eyeing production, the pragmatic reading is to treat “no encryption by default” as a design premise and plan the network boundary around it.
Roadmap: v2.0, DuckLake, and Read Replicas
The first production release lands with DuckDB v2.0 in fall 2026. After that: DuckLake integration so a remote DuckDB can serve as a DuckLake catalog, auto-install and auto-load of the extension, higher transaction throughput, extensible protocol messages, and a replication protocol for read replicas. The team credits Boaz Leskes of MotherDuck for protocol design lessons and Philip Moore of GizmoSQL, who built client-server DuckDB before the core team did. More details are promised at DuckCon #7 on June 24, 2026.
Sources
- Quack: The DuckDB Client-Server Protocol — DuckDB
- duckdb/duckdb-quack — GitHub
- Quack: The DuckDB Client-Server Protocol — Hacker News
AI-assisted summary compiled from the sources above, reviewed by a human before publishing.