DuckDB Previews v2.0 "Cyanoptera," Replacing Its Postgres-Derived Parser With a PEG Grammar Ahead of a Fall Release

Overview

DuckDB’s core team previewed version 2.0 of the embeddable analytical database, codenamed “Cyanoptera” after the cinnamon teal, a duck species, according to DuckDB’s official blog. The preview post, written by DuckDB Labs co-founders Mark Raasveldt and Hannes Mühleisen, says “DuckDB v2.0 is coming this fall” and outlines a set of headline changes that include a client/server mode, database triggers, a new default storage format, and a replacement for the SQL parser DuckDB has used since its earliest commits.

Three days after the preview post, DuckDB engineer Daniël ten Wolde published a deep-dive on the most technically significant of those changes: a rewrite of the parser itself. “DuckDB v2.0 replaces its PostgreSQL-derived SQL parser with a PEG-based parser that is easier to evolve and can be extended at runtime,” the post states. As of this writing, DuckDB’s most recent tagged release remains v1.5.5, published July 22, 2026, and there is no v2.0 tag yet on the project’s GitHub releases page — consistent with the fall timeline the team has set for itself.

Why the Parser Is Being Replaced

DuckDB has “famously always used a parser derived from PostgreSQL’s,” according to the preview post, which adds: “We have decided that enough is enough: v2.0 ships our own modern, extensible PEG-based parser.” The parser deep-dive traces that lineage further, noting the PostgreSQL-derived grammar “was already part of the first commit to DuckDB in 2018,” according to the post.

That grammar is built with YACC/Bison, a parser-generator technology the post says has become difficult to extend: “seemingly small additions to the grammar can interact with existing rules and introduce shift/reduce or reduce/reduce conflicts,” the post explains. The replacement uses parsing expression grammar (PEG), a technology the post compares to a change Python made years earlier: “Python switched from its LL(1) parser to a PEG-based parser in Python 3.9, also motivated by additional flexibility,” it notes.

The post walks through how the parser fits into DuckDB’s query pipeline, distinguishing it from two neighboring stages: the parser “determines whether these tokens follow DuckDB’s grammar and produces a ParseResult tree,” while a separate transformer “converts the generic parse results into DuckDB’s internal abstract syntax tree (AST),” according to the post. It also draws a line between parsing and binding: “The parser determines whether a query is syntactically valid, while the binder determines whether the tables, columns, and functions it refers to actually exist,” the post states — illustrated with a malformed query (SELECT * WHERE true FROM range(1);) that returns “Parser Error: syntax error at or near “FROM"", versus a syntactically valid but nonexistent-table query (FROM missing_table;) that instead returns “Catalog Error: Table with name missing_table does not exist!”.

A Parsing Bug Fixed With Memoization

The parser post also documents a performance problem the old grammar had with malformed queries containing long runs of unmatched parentheses, such as SELECT ((((((((((((((((((;. Benchmarking that pattern against the old parser, the team found the time cost exploded as parentheses were added: “18 opening parentheses: 5.303 seconds” and “19 opening parentheses: 10.640 seconds”.

The new PEG parser avoids that blowup using a technique called packrat parsing, which memoizes intermediate results: “For each memoized matcher, we store the result of applying it at a particular token position,” the post explains. With packrat parsing enabled, the same 19-parenthesis query that previously took over ten seconds instead resolves in “0.001 seconds”.

The new parser architecture is also designed to be extensible by third parties at runtime. The post notes that syntax-adding extensions “already exist, such as psql and duckpgq, but under the hood they work as fallback parsers” today, according to the post — workarounds the new architecture is meant to replace with direct grammar registration. As a demonstration, the post shows an extension implementing Google’s pipe-syntax SQL variant, letting a query such as FROM produce |> WHERE item != 'bananas' |> AGGREGATE COUNT(*) AS num_items GROUP BY item |> ORDER BY item DESC; run against DuckDB. Despite the rewrite, the team says compatibility is preserved for current users: “Existing DuckSQL queries should continue working as before”, though the runtime grammar-extension API itself remains “a preview and may change before v2.0 is released”.

The Rest of the v2.0 Preview

The parser is one piece of a broader release the preview post frames as a shift in what DuckDB is. “Where last year was the year of the lakehouse, this release kicks off the year of DuckDB as a server,” the post says. DuckDB has run only as an in-process, embedded database since its creation, but the team writes that “people have asked us — very persistently — for a client/server mode, and we have finally caved,” according to the preview; in the new mode, “any DuckDB process can serve its databases over the network, and any other DuckDB can attach to it”. The post also pushes back on an assumption about DuckDB’s transactional capabilities: “DuckDB has been built as a transactional, multi-connection database with full MVCC and transaction isolation since day one,” it states.

Other headline additions include full trigger support — “BEFORE and AFTER triggers, FOR EACH ROW and FOR EACH STATEMENT”, which the team says addresses “a long-standing feature request” — and a storage format change: “DuckDB v2.0 bumps the default storage format version to v2.0.0”, with column metadata now “loaded lazily, so wide tables open faster too,” according to the post. Asynchronous I/O is also arriving for object-store access, since “synchronous access placed a limit on how fast this could go,” the post notes; in one microbenchmark for recursive queries, the team reports “DuckDB v2.0 is about 40\u00d7 faster (!)” than v1.5.4.

The release also removes a long-standing dependency: “In v2.0, the ICU library is gone entirely: the icu extension now implements timezones, calendars, and collations itself,” the post says, after noting the library had powered timezone-aware timestamps since early on even though “we only ever used a small slice of it,” according to the post. Extension authors get a new interface too: DuckDB “will ship with a revamped C API” with “a versioned specification expressed in YAML,” the team writes, with “a large part of the API” marked stable and frozen “across DuckDB versions,” and support for organizations to “register your own trusted repositories” to host and sign their own extensions. The team says the release reflects “more than 10,000 commits by many contributors since we released v1.5”.

What We Don’t Know

DuckDB has not published a specific release date for v2.0 beyond “this fall,” and both posts describe several pieces — including the runtime grammar-extension API — as previews still subject to change before the final release. The full list of breaking changes tied to the new default storage format has not yet been published in detail.

Background

DuckDB is an open-source, in-process analytical database widely used for local and embedded data analysis. The Machine Herald previously reported on the release of DuckDB 1.5.0 in March 2026, which introduced the VARIANT semi-structured data type and a built-in GEOMETRY type, and which at the time already flagged a DuckDB 2.0 milestone as forthcoming.