DuckDB v2.0 Preview: The Embedded Database Grows a Server Mode
DuckDB v2.0 Preview: The Embedded Database Grows a Server Mode
On August 17, 2026, DuckDB co-creators Mark Raasveldt and Hannes Mühleisen published "A Preview of DuckDB v2.0". The stable release lands this fall, but preview builds already run most of what they announced.
Since v1.5 shipped in March, the project has accumulated more than 10,000 commits. The v2.0 codename is "Cyanoptera" (the cinnamon teal), and what it does is more radical than a version bump: a database that built its identity on being in-process and dependency-free now officially has a server mode.
One thing to clear up first. As this news spread, two numbers traveled with it: "aggregate queries 40x faster" and "compression improved by 20%." We checked the official post line by line — the 40x is real but the workload isn't aggregation, and the 20% figure never appears in the post at all. Here's the fact-checked version.
The 40x Is Real — But the Star Is Recursive CTEs
The official post contains exactly three performance multipliers, and the big one belongs to recursive CTEs: a single-source reachability query over a graph with one million edges takes 4.90 seconds on v1.5.4 and 0.12 seconds on the v2.0 preview. The post itself adds the exclamation mark: "about 40× faster (!)".
That comes from a rewrite of the recursive query executor — a genuine win if your workload involves graph traversal, hierarchy expansion, or BOM explosion. If your pipeline is ordinary GROUP BYs and window functions, do not budget for 40x.
Aggregation did improve, but the post gives no multiplier for it: partial aggregates can now be pushed below joins, redundant aggregates get reused, and aggregations spill to disk when they exceed memory. The other two published numbers: Windows CLI result materialization got ~2.2x faster with multithreading, and after replacing ICU with an in-house implementation, timezone conversion over 25 million rows went from 0.24s to 0.11s (2.2x).
This is a good refresher on how to read vendor benchmarks: find the exact scenario behind the number before deciding whether it applies to you. Running your three slowest production queries against the preview beats retweeting any headline.
The Real Headline: CONNECT and the Quack Protocol
Products in the SQLite lineage have upheld a decades-old doctrine: embedded databases don't do networking. v2.0 tears that up.
The new CONNECT / DISCONNECT statements, together with the now-stable quack extension (DuckDB's native wire protocol), let one DuckDB instance connect to a remote one — or even CONNECT 'postgres://...' straight into PostgreSQL, with a new remote pushdown optimizer shipping SQL to the far end for execution.
A comment on the 531-point Hacker News thread captured the mood: over the past year DuckDB has been sliding from an in-process analytics engine toward "the foundation of a cloud data warehouse." Another user offered a more grounded scenario: their team had been managing multi-GiB .duckdb files as runtime artifacts, and client/server mode finally lets that "single file as a database" deployment be managed centrally like a real database server.
DuckDB's answer: the engine has had full MVCC and transaction isolation since day one — single-user setups just never needed them. Now that infrastructure is open for business.
VARIANT Graduates: "Imagine If JSON Were Fast"
The semi-structured VARIANT type becomes a first-class citizen in v2.0: shredded storage executes directly, extraction predicates push down, Parquet shredded VARIANT reads and writes are in, plus a family of variant_* functions. The team also previewed that after v2.0, the plain JSON type will sit on top of VARIANT — meaning existing JSON queries get faster for free.
For logs, analytics events, and API payloads — data whose schema changes weekly — this is the feature most worth testing.
Also Worth Noting
- Triggers, fully delivered: BEFORE/AFTER, FOR EACH ROW/STATEMENT, transition tables, DROP TRIGGER.
- A brand-new SQL parser: the PostgreSQL-derived parser is gone, replaced by an in-house PEG parser that lets extensions inject their own syntax. The first dialect compatibility mode is
SET dialect_compatibility_mode = 'spark'— a clear shot at the Spark SQL migration market. - Async I/O throughout the engine: Parquet, CSV, and the native format are all asynchronous now, with new MMAP and DIRECT_IO modes and substantially faster object-storage reads.
- De-ICU: timezones, calendars, and collations are now implemented in-house, with IANA timezone data compressed to ~45 kB. One HN commenter reacted to "We reimplemented ICU" with a scream emoji — this is famously treacherous territory. Bold move; risks acknowledged.
- A stable C API: extensions become "write once, works forever," with the API generated from a declarative YAML spec, plus support for self-hosted signed extension repositories.
The New Storage Format: What's True and What Isn't
The real selling points of storage format v2.0.0: ART indexes are now buffer-managed (no longer pinned in memory, so tables with large indexes open instantly), column metadata loads lazily, DICT_FSST string compression is on by default, and deletes are stored compactly. The official summary is "open faster and use far less memory" — there is no "20% better compression" claim anywhere. Please stop passing that number along.
On compatibility: since v0.10, DuckDB guarantees newer versions can always read older files, so "old files won't open" is false. The reverse isn't guaranteed — files written in the new v2.0 format may not be readable by older versions, and teams that need cross-version collaboration can pin the old format with storage_compatibility_version. The post is upfront that v2.0 ships "a small set of breaking changes" (the new default storage format, the completed lambda syntax transition), with details reserved for the release announcement.
What's Missing, and What to Do
The sharpest HN criticism: DuckDB still has no incremental materialized views — which the commenter called "ClickHouse's best feature," noting that the building blocks (aggregate state export/finalize) already exist inside DuckDB, making the omission look deliberate. The v2.0 feature list indeed doesn't include it.
Three takeaways for teams running DuckDB:
- Install the preview; don't rush production — stable lands in the fall and the full breaking-changes list isn't out yet.
- Benchmark your own slow queries, especially recursive CTEs and heavy VARIANT/JSON workloads — your gains may far exceed the averages.
- If you're waiting for it to replace ClickHouse, first confirm you don't depend on incremental materialized views.
A project that went open source in 2019 has reached v2.0 in five years, with 10,000 commits in six months (HN is already asking how many were written by AI). Whatever the answer, that iteration speed is itself the scariest competitive advantage in embedded analytics.
Sources: DuckDB official blog: A Preview of DuckDB v2.0 DuckDB official blog: Asynchronous I/O in DuckDB Hacker News discussion (531 points): A Preview of DuckDB v2.0 DuckDB storage compatibility docs: Storage Versions and Format