Summary: On May 12, 2026, DuckDB introduced Quack, an experimental remote protocol that lets one DuckDB instance connect to another as client or server. It uses HTTP and the application/duckdb MIME type, with the first production release planned alongside v2.0 in fall 2026. The article notes no encryption by default and recommends a reverse proxy for public service.
On May 12, 2026, the DuckDB team unveiled Quack, a remote protocol whose premise is literal: one DuckDB instance can now connect straight to another. One and the same binary plays both roles, client and server, so several independent processes — whether on a single machine or spread across many — can modify tables concurrently without blocking one another. It arrives today as an experimental extension, with the first production release slated to land alongside DuckDB v2.0 in fall 2026.
This fills a hole the project has carried for years. DuckDB bet on an in-process design from day one — the same wager as SQLite — and the bet paid off in the data-science notebook and embedded-SQL worlds, yet “multiple processes writing to the same data” never received an official answer. The team puts it plainly: user experience is what they care about, and having the last word in the architecture debate matters far less.
How Quack Works
Quack sits directly on HTTP, with the surrounding networking stack tuned around it. Messages travel under a new MIME type, application/duckdb, whose payloads recycle DuckDB’s internal serialization primitives — machinery it shares with the write-ahead log, and which the team calls battle-tested. The traffic pattern is client-driven request-response: once connected, a query costs a single round trip, and large results keep flowing through follow-up fetch messages that can run across threads in parallel. Quack comes native to DuckDB-Wasm, so a DuckDB inside a browser tab can reach a DuckDB server on EC2. The default port is 9494 — a wink at 1994, when Netscape Navigator first hit the market. A server comes up via CALL quack_serve, with a token supplied; the client, in turn, registers a quack secret and then issues ATTACH. The extension is published under an MIT license in the duckdb/duckdb-quack repository and installs itself automatically on first use.
The Case Against Arrow Flight SQL
Two considerations settled it. One, Flight SQL is an interchange format governed outside the project, and adopting it would chain DuckDB’s protocol evolution to somebody else’s timetable. Two, Flight SQL requires two round trips for every query — first a CommandStatementQuery, then a DoGet — and that overhead lands hardest on the small, frequent transactions DuckDB users care about. Nor was the need hypothetical, the team concedes: the community had already been improvising custom RPC layers, Arrow Flight SQL adapters, MotherDuck’s proprietary protocol, and “EleDucken” setups that put PostgreSQL in front via pg_duckdb.
Benchmarks: What a Single Round Trip Buys
Tests ran on an AWS m8g.2xlarge with 8 vCPUs, 32 GB RAM, roughly 15 Gbps of network, and a 0.28 ms ping. Moving the TPC-H lineitem table in bulk: 60 million rows take 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 times read 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, measured as the median of five runs, a single thread keeps up 1,038 tx/s on Quack, versus 469 on Arrow and 839 on PostgreSQL; push to eight threads and the figures become 5,434 against 1,358 and 4,320. The pitch line goes: “the fastest way to shove tables through a socket.” The caveat deserves equal billing: beyond eight threads, PostgreSQL scales better, hemmed in by a DuckDB concurrent-insert limit that is already on the roadmap.
Security Posture and Present-Day Limits
Every server start mints a random auth token, and by default the server binds to localhost only. SSL does not ship enabled; to serve the public, the guidance is to put a reverse proxy such as nginx in front and pair it with Let’s Encrypt. Both authentication and authorization can be swapped out — the token check accepts custom code, and the authorization callback can be written as a plain SQL macro, LDAP lookups being one example. On maturity the team is explicit: this is a pre-release, experimental extension, its repository’s Releases page still lists nothing, and bug reports belong on GitHub. The Hacker News thread, meanwhile, has collected 387 points and 83 comments. Teams weighing production adoption should read “no encryption by default” as a design premise and lay out the network boundary accordingly.
What Comes Next: v2.0, DuckLake, Read Replicas
The first production release rides along with DuckDB v2.0 in fall 2026. Queued behind it: DuckLake integration, making a remote DuckDB usable 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. Credit is given where due — Boaz Leskes of MotherDuck for lessons on protocol design, and Philip Moore of GizmoSQL, who had a client-server DuckDB working before the core team got there. The next round of specifics is promised at DuckCon #7 on June 24, 2026.