DuckDB 2.0 turns the embedded engine into a server

DuckDB has previewed version 2.0, due in autumn 2026. The headline change reverses the premise most people hold about the engine: any DuckDB process can now serve databases over the network through the Quack protocol, with a `CONNECT` statement on the client side and a remote pushdown optimiser that sends SQL straight to PostgreSQL and MySQL.

The rest of the list

• VARIANT becomes a first-class type, with shredded execution from storage and extraction pushdown for semi-structured data.
• Triggers arrive in full: BEFORE and AFTER, per row and per statement, with transition tables.
• New SQL: NEAREST joins for similarity search, DML inside CTEs, nested schemas, JSON mutation functions, recursive CTEs with USING KEY.
• Asynchronous I/O scales object-store access independently of query processing.
• A PEG-based parser replaces the PostgreSQL-derived one, bringing dialect compatibility modes and better error messages.

The published speed-ups are specific rather than general: a recursive CTE reachability query drops from 4.90s to 0.12s, a 40× improvement; timezone conversion over 25 million rows is 2.2× faster; German collation filtering over 5 million rows, 2.6× faster.

Two housekeeping details are worth more than they look. The ICU dependency is gone, with timezone and calendar data now embedded at about 45 kB, and a stable C API means extensions can be written and built once rather than per version.

Plan for the breaking part. The storage format changes by default and the lambda syntax transition completes, with details promised at release. An engine that has been reliably drop-in for years is about to require a migration step.