DuckDB 2.0 'Cyanoptera' Adds Client/Server Mode, Triggers, and a First-Class VARIANT

DuckDB is preparing a rare major-version bump this fall, and the headline shift is philosophical: the long-standing in-process database is becoming something you can run as a server. The stabilized ‘quack’ extension lets any DuckDB process serve its databases over the network while others attach and route queries via the new CONNECT statement. That same statement, paired with a remote pushdown optimizer, can also ship SQL directly to PostgreSQL and MySQL rather than dragging tables across the wire. The project leans on the fact that DuckDB has quietly shipped full MVCC and transaction isolation since day one, arguing it can now hold its own against general-purpose databases in multi-tenant, long-running deployments—backed by new metrics, logging, and observability work.

The release is dense with SQL-level features drawn from more than 10,000 commits since v1.5. The VARIANT type—essentially schema-free JSON that DuckDB ‘shreds’ into a fast, well-compressed columnar form—becomes first-class, with pushdown into scans and Parquet read/write, positioning it for log ingestion and evolving semi-structured data. Full trigger support (BEFORE/AFTER, row and statement level, transition tables) lands after years of requests. Dialect additions include NEAREST joins for vector similarity search, DML inside CTEs, nested schemas, a terser $variable syntax, in-place JSON mutation functions, and recursive CTEs with key-based aggregation.

Underneath the SQL surface, v2.0 rewrites core machinery: a new SQL parser, a new default storage format, a reworked C API, asynchronous I/O to better exploit object stores like S3, and a rebuilt recursive CTE engine. A handful of deliberate breaking changes come with the territory, but the framing is unambiguously feature-first—the codename ‘Cyanoptera,’ after the cinnamon teal, marks a release the team pitches as the start of ‘the year of DuckDB as a server.’