DuckDB Spent Ten Years Not Being a Server. Version 2.0 Is One.
DuckDB has been an in-process database since day one. In the version 2.0 preview, the maintainers wrote this:
"people have asked us — very persistently — for a client/server mode, and we have finally caved."
Ten years of position, ended in one sentence by the people who built it.
This is a teardown of what that decision actually ships, and what it costs you.
🔔Subscribe: / @stack_current
Quack — the extension implementing DuckDB's native protocol. One call, quack_serve, turns any process into a server. No daemon, no second binary
CONNECT — attach a remote database under an alias, point your whole session at it, and queries execute there while results stream back
The part with the widest blast radius: CONNECT is not limited to DuckDB. A new remote pushdown optimiser ships SQL directly to PostgreSQL and MySQL instead of pulling their tables over the wire
The belief that was already wrong — DuckDB has had full MVCC, multi-connection support and transaction isolation since day one. Most people never noticed because they were the only user
What a server forces you to build: reworked metrics, logs and observability, because a process that never exits is somebody's on-call rotation
Triggers, arriving complete — BEFORE and AFTER, FOR EACH ROW and STATEMENT, transition tables. You do not audit a script that opens a file and exits
The storage format went the other way: buffer-managed ART indexes are no longer pinned in memory, column metadata loads lazily, and databases with big indexes open faster using far less memory
Asynchronous I/O throughout the engine, so the storage layer scales independently of query processing. Network storage is where the gains land
The number you can reproduce on a laptop: a recursive CTE over one million edges runs in 4.90s on v1.5.4 and 0.12s on the v2.0 preview — about 40×
They deleted ICU entirely. Timezone data now comes from IANA compressed to around 45 kB, and converting 25 million timestamps drops from 0.24s to 0.11s. Smaller and faster, not a trade
A new PEG-based parser replacing the PostgreSQL-derived one, with extensions able to hook into the grammar itself
Signed extension repositories you host yourself, with pinned public keys and printed SHA-256 fingerprints — still work in progress
The honest limit: this is a preview, not the release. Version 2.0 ships a small set of breaking changes, including the new default storage format and the finished lambda syntax transition, and that list has not been published yet. The migration cost is genuinely unknown today. Anyone quoting you an upgrade effort right now is quoting a number that does not exist.
The verdict splits. If DuckDB is a library inside your process, nothing forces you to move, and the faster recursive queries and lighter index loading reach you anyway. If you built queues, sync jobs and glue services around it because it could not be shared, the server mode deletes that layer — test the preview now, and upgrade when the breaking-change list lands.
Every figure above comes from the maintainers' own preview post. Nothing here was benchmarked by this channel.
Chapters
text
0:00 They said it themselves
0:30 Cyanoptera, this autumn
1:01 Three questions this answers
1:27 Nothing was fixed. Nothing was broken.
1:59 One call, and the process is a server
2:29 The session points somewhere else
2:57 The query moves to the data
3:31 The world built its own clients
4:03 A library that never exits becomes infrastructure
4:35 Triggers arrive complete
5:10 More features, less memory
5:44 The storage layer stops waiting
6:18 Forty times, on the same SQL
6:53 They deleted ICU and got faster
7:32 A new parser you should not notice
8:06 Host and sign your own extensions
8:42 Nobody can price the upgrade yet
9:13 Two answers, depending on what you built
Timings are taken from public/stack-current/duckdb-2-server/voiceover-metadata.json, not estimated from word count. Total runtime is 9:50.
Primary sources
DuckDB — A Preview of DuckDB v2.0, by Mark Raasveldt and Hannes Mühleisen: https://duckdb.org/2026/08/17/duckdb-...
Single source by design. Every claim in this episode is the maintainers describing their own release, and the description says so. Where they state a benchmark, the video attributes it to them rather than presenting it as an independent measurement.
#DuckDB #Database #dataengineering