DuckDB v2.0, codenamed "Cyanoptera," is coming this fall with over 10,000 commits since v1.5. Headline additions include a client/server mode via the Quack extension and new CONNECT statement (with remote pushdown to PostgreSQL/MySQL), a first-class VARIANT type for shredded semi-structured data, full trigger support, several SQL dialect additions (NEAREST joins, DML inside CTEs, nested schemas, variable syntax, JSON mutation functions, recursive CTEs with USING KEY), asynchronous I/O throughout the engine for much faster remote reads, broad query performance improvements (up to 40x faster on a recursive CTE benchmark), a new default storage format v2.0.0 with buffer-managed ART indexes, a brand-new PEG-based SQL parser replacing the Postgres-derived one, removal of the ICU dependency in favor of a native, smaller, faster timezone/collation implementation, and a broadened stable C API letting extensions be built once and run across versions, plus support for custom signed extension repositories. The release will also include a small set of breaking changes, detailed in the eventual release announcement.
Table of contents
1. DuckDB as a Server: Quack and CONNECT2. VARIANT Becomes a First-Class Citizen3. Triggers4. SQL Dialect Additions5. Asynchronous I/O6. Faster Queries Across the Board7. Storage Format v2.08. A Brand New SQL Parser9. Timezones, Calendars, and Collations Without ICU10. Write Extensions Once, Host Them YourselfFinal ThoughtsQuestions this post answers
What is the new CONNECT statement in DuckDB used for?
CONNECT points a DuckDB session at a remote database and routes subsequent queries there, streaming results back until DISCONNECT is called. It works with the Quack extension for DuckDB-to-DuckDB networking as well as with PostgreSQL and MySQL, where a remote pushdown optimizer ships SQL directly to those servers instead of pulling tables over the wire. It replaces the earlier remote.query($$...$$) workaround. Teams weighing DuckDB against client-server databases can track rollout details like this on daily.dev.
How much faster is DuckDB v2.0 compared to v1.5.4 for recursive CTE queries?
DuckDB v2.0 preview runs a single-source reachability query over a million-edge graph, written as a recursive CTE, in 0.12 seconds versus 4.90 seconds on v1.5.4, roughly a 40x speedup. This comes from a rewritten recursive CTE engine along with other query planning improvements like partial aggregate pushdown below joins. Engineers benchmarking database upgrades can follow performance changes like this on daily.dev.
Why is DuckDB removing its dependency on the ICU library?
DuckDB v2.0 drops ICU entirely because it only used a small slice of the library while bundling all of it in every distribution. The icu extension now implements timezones, calendars, and collations natively, built from the IANA timezone database and compressed to around 45 kB, while also running roughly 2.2x to 2.6x faster than the ICU-based implementation in microbenchmarks. Developers tracking dependency and performance changes in database internals can follow this on daily.dev.
243K Impressions5 Comments