The DuckDB project previewed DuckDB v2.0, a planned fall release that marks a significant step for the in-process analytical database. The project said the new version will be called “Cyanoptera,” after the cinnamon teal, and described the release as both a feature expansion and a major-version change with selected compatibility breaks.

The preview identified several headline changes: DuckDB operating as a server, triggers, the VARIANT type, asynchronous I/O, a new SQL parser, a new default storage format and a reworked C API. The project said the move to v2.0 reflects more than branding, noting that the release follows more than 10,000 commits since DuckDB v1.5 was released in March.

A central theme is client/server use. DuckDB has traditionally been known as an embedded database, running inside a host process rather than as a separate service. In v2.0, the quack extension, which implements a native DuckDB protocol for communication between DuckDB instances, is set to become stable. The project said any DuckDB process will be able to serve its databases over a network, while another DuckDB instance can attach to it and route queries through a new CONNECT statement.

The same direction extends beyond DuckDB-to-DuckDB connections. According to the preview, CONNECT can target remote databases that support it, and a remote pushdown optimizer will send SQL directly to PostgreSQL and MySQL rather than first transferring tables into DuckDB. The project framed this as part of a broader shift toward long-running and multi-tenant DuckDB deployments, supported by work on metrics, logs and observability.

DuckDB v2.0 also expands support for semi-structured data. The VARIANT type, introduced in DuckDB v1.5, can store rows with differing shapes while allowing DuckDB to detect shared structure internally. The preview said v2.0 completes more of that pipeline with execution from storage, scan-level extraction pushdown, Parquet read and write support for shredded VARIANT data, and new variant-related functions.

Triggers are another major SQL feature in the preview. DuckDB said v2.0 will support BEFORE and AFTER triggers, row-level and statement-level triggers, transition tables using OLD and NEW table references, multiple triggers per event, RETURNING on triggered tables and DROP TRIGGER. The project described audit tables as a typical application and said triggers also fit the longer-running service model.

Other SQL additions include NEAREST joins for similarity search, data modification statements inside common table expressions, nested schemas, a shorter variable syntax, JSON mutation functions, recursive CTEs with USING KEY aggregation, SQL-standard FETCH FIRST syntax, OVERLAY(), UNNEST in GROUP BY, and clarified behavior for MERGE and UPDATE ... FROM when multiple matches occur.

At the engine level, DuckDB v2.0 introduces asynchronous I/O. The project said the change is aimed particularly at object stores such as S3, where remote reads can bottleneck query execution. Parquet support is listed first, followed by CSV and DuckDB’s own file format, along with asynchronous Parquet writes and new MMAP and DIRECT_IO modes.