A Preview of DuckDB v2.0

TL;DR: DuckDB v2.0 is coming this fall. In this post, we preview its headline features: DuckDB as a server, triggers, the VARIANT type, asynchronous I/O, a new SQL parser, a new storage format, and much more.

DuckDB v2.0 will be named “Cyanoptera” after thecinnamon teal(Anas cyanoptera),a strikingly reddish-brown duck found in the western Americas.

A major version bump is not something we do lightly, and it is not just ceremony: v2.0 ships a new SQL parser, a new default storage format, a reworked C API, and a small number of carefully chosen breaking changes. But above all, it is a feature release, built from over 10,000 commits since we released v1.5 in March. Where last year was the year of the lakehouse, this release kicks off the year of DuckDB as a server. We previewed many of these features in the“State of the Duck” talk at DuckCon #7, if you prefer to watch instead of read.

DuckDB is moving rather quickly, and we can only cover a small fraction of the changes here. Condensing all new features down to a shortlist is always a fight over what gets in, and yes, we know that what follows is technically a listicle(Ten Things Coming to DuckDB v2.0, Number Eight Will Shock You).We are not proud of the format, but it works, so here it is, starting with the SQL-level features and working down into the engine.

DuckDB has been an in-process database since day one. But people have asked us – very persistently – for a client/server mode, and we have finally caved. Thequackextensionimplements DuckDB’s native protocol for talking to other DuckDBs. It wasreleased as a previewshortly before DuckCon #7, graduates to stable in v2.0, and it is a big part of where DuckDB is headed: any DuckDB process can serve its databases over the network, and any other DuckDB can attach to it and route queries there using the newCONNECTstatement. For example:

CONNECTis the successor to theremote.query($$…$$)workaround we showed when Quack was first revealed – we looked at that syntax and said: no, this cannot be it. AndCONNECTis not limited to Quack: it points your session at any remote database that supports it, and the new remote pushdown optimizer (#22914) ships SQL directly to PostgreSQL and MySQL instead of pulling tables over the wire:

If you have worked with analytical systems in the past, you may assume that DuckDB cannot handle transactional workloads. But DuckDB has been built as a transactional, multi-connection database with full MVCC and transaction isolation since day one. Most users just never needed that in a single-user scenario. It turns out DuckDB handles transactions well: it’s fast enough to compete with general-purpose databases like PostgreSQL on quite a few workloads, and the client/server pattern finally lets that machinery shine in multi-tenant, long-running deployments.

Running DuckDB long-term also comes with new challenges, which is why v2.0 pushes on better metrics, logs, and observability (see, e.g., the metrics layer rework in#22799) that let you look at a DuckDB instance and see what it is actually doing. People even built standalone clients for the Quack protocol within weeks of the preview. We thought we were extending DuckDB to talk to other DuckDBs; the world said no, no, no, and built their own clients. Who would have thought.

In v2.0, this pipeline works end to end: shredded execution straight from storage (#20912), extraction pushdown into scans (#22478), shreddedVARIANTreadingandwriting for Parquet, and a family ofvariant_*functions:

Longer term, likely soon after v2.0 (but don’t hold us to it), we plan to back the regularJSONtype withVARIANT, so existing JSON workloads get all of these benefits without changing a single query.

Triggers have been a long-standing feature request, and DuckDB v2.0 delivers them in full:BEFOREandAFTERtriggers,FOR EACH ROWandFOR EACH STATEMENT, transition tables viaREFERENCING OLD/NEW TABLE, multiple triggers per event,RETURNINGon triggered tables, andDROP TRIGGER.

The classic use case is audit tables: something happens in the system, and a trigger records what changed. For example: