On August 17, the DuckDB team published a preview of version 2.0 — codename Cyanoptera, with a fall 2026 release planned. Since the 1.5 release in March, more than 10,000 commits have accumulated, and some changes reshape the understanding of what DuckDB is.
The main takeaway is — a built-in server role. A Quack protocol and a CONNECT operator have appeared, routing a query to a remote database, including PostgreSQL and MySQL, with automatic forwarding of filters and projections to the remote side. In other words, a “self-contained analytics database in one file” stops being purely embedded: one process can now serve clients over the network.
This is a preview, not a release. Everything described has been announced by the developers as content for a future version; you’ll be able to test it on your load closer to autumn. The figures below come from the official announcement; independent measurements are not yet available.
Second in importance are — triggers that didn’t exist in DuckDB before. They include BEFORE, AFTER, and row-level FOR EACH ROW, and for the entire FOR EACH STATEMENT operator, along with transition tables through REFERENCING OLD/NEW TABLE. For a database that has typically been considered a “read-mostly engine over Parquet,” this is a notable step toward full OLTP semantics.
The numbers promise
The loudest result is the rewritten recursive CTE engine. On a reachability-in-graph query:
| Version | Time |
|---|---|
| v1.5.4 | 4.90 s |
| v2.0 | 0.12 s |
That’s roughly a fortyfold acceleration. Separately, ICU library was dropped: time zones, calendars, and collations are now implemented inside, IANA data packaged in about 45 KB. A side effect is smaller builds and faster operations: converting time zones on 25 million rows is 2.2x faster, and filtering with German collation on 5 million rows is 2.6x faster (developers’ measurements on a MacBook).
Asynchronous I/O was added for Parquet, CSV, and the native format, plus MMAP and DIRECT_IO modes for local disks. The storage format was updated to version 2.0: ART indexes are no longer pinned to memory and are managed by a buffer; column metadata is loaded lazily, and DICT_FSST string compression is enabled by default. They claim large tables with indexes will open instantly, loading what’s needed on demand.
What’s new in SQL itself
- Nearest joins for finding top-k similar records;
- DML inside CTE —
INSERT,UPDATE,DELETE,COPY; - nested schemas:
CREATE SCHEMA finance.reports; - variables via
$variable_name; - JSON mutation functions:
json_set,json_insert,json_replace,json_remove; - recursive CTEs with aggregation
USING KEY; - standard
FETCH,OVERLAY, and refinedMERGEsemantics.
The VARIANT type is a separate story; the authors describe it as “imagine JSON is fast”: it now can perform shredded execution directly from storage, with field extraction forwarding and read-write in Parquet using specialized variant_* functions.
Under all of this is a new PEG-based parser instead of the PostgreSQL-derived one. Practical benefits are twofold: extensions can attach their own syntax, and error messages point to the exact location. At the same time, a compatibility mode for dialects was added, for example SET dialect_compatibility_mode = 'spark'.
For extension authors, a stable C API is provided, generated from versioned YAML specifications, and dedicated extension repositories with RSA signing:
CREATE EXTENSION REPOSITORY my_repo FROM 'https://extensions.example.org';
Why would this matter to someone running a home server
DuckDB has long been convenient for log analysis: feed it a directory of nginx access logs or an Xray statistics dump and compute everything with a single query, without deploying a separate DBMS. Asynchronous I/O and lazy metadata hit exactly this scenario — “open a large archive and start reading immediately.” And the CONNECT to PostgreSQL will allow joining fresh Parquet files with a live database without unloading it entirely.
organizational: in autumn 2026, a consultative council of interested parties will be launched under the DuckDB Foundation, which will influence the development of DuckDB, DuckLake, and Quack. How this will affect speed and direction of development is yet to be determined; for now this is just an announcement of the structure.
Sources
Who keeps DuckDB in the operational loop — what does it actually win against PostgreSQL for you, and what does it lose? And is a server role even needed: wouldn’t it be simpler for network access to deploy a proper DBMS and leave DuckDB where it already shines?