DuckDB v2.0 preview: a server mode, triggers and a new storage format

DuckDB has published a preview of version 2.0, the next major release of the in-process analytical database, due this autumn and named Cyanoptera after the cinnamon teal. The release follows more than 10,000 commits since v1.5 shipped in March, and the project describes it as the start of "the year of DuckDB as a server".

A server mode at last

The headline change is client/server support. The quack extension, first shown in May, implements DuckDB's own protocol and becomes stable in v2.0: any DuckDB process can serve its databases over the network, and another DuckDB can attach to it and route queries there with the new CONNECT statement. CONNECT is not limited to DuckDB — aimed at a PostgreSQL or MySQL server it sends SQL to the remote system instead of pulling tables across the wire, through a new remote pushdown optimizer. The team notes that DuckDB has been transactional with full MVCC from day one, an advantage that now matters in multi-tenant, long-running deployments. Metrics and logging were reworked for the same reason.

VARIANT, triggers and SQL additions

The VARIANT type, introduced in v1.5, becomes a first-class citizen: shredding happens straight from storage, extraction is pushed into scans, Parquet reads and writes support it, and a family of variant_* functions arrives. The maintainers plan to back the regular JSON type with VARIANT soon after the release, so existing JSON workloads gain the same benefits without query changes.

Triggers ship in full: BEFORE and AFTER, FOR EACH ROW and FOR EACH STATEMENT, transition tables through REFERENCING OLD/NEW TABLE, multiple triggers per event, RETURNING and DROP TRIGGER. The classic use case is an audit table that records what changed.

The SQL dialect gains top-k similarity search as a join clause (APPROX NEAREST, aimed at vector and embedding workloads), DML inside CTEs, nested schemas, a $variable syntax, JSON mutation functions such as json_set, and recursive CTEs with USING KEY aggregation.

Faster I/O, faster queries, signed extensions

Asynchronous I/O now runs throughout the engine, so the I/O layer scales independently of query processing — Parquet first, then CSV and DuckDB's own format, plus new MMAP and DIRECT_IO modes. The largest gains appear on network storage. On the query side, partial aggregates are pushed below joins, the recursive CTE engine was rewritten, aggregations spill to disk when they outgrow memory, and the Windows CLI became roughly 2.2× faster at multi-threaded result materialization.

Extensions get a reworked stable C API and, still in progress, user-registered repositories that distribute RSA-signed extensions whose SHA-256 fingerprints are printed at registration. From the autumn the DuckDB Foundation will add a stakeholder advisory board advising on the roadmaps of DuckDB, DuckLake and Quack. Preview builds already include most of these features, though the team warns that details may still shift before the autumn release.