# DuckDB 2.0 enters feature freeze with alpha builds ahead of an October release DuckDB 2.0 has moved from architectural preview into feature freeze: Python and CLI alpha builds are now installable, core extensions are being tested against the 2.0 branch, and the team is targeting a stable release in October. The architecture is unchanged—Quack/CONNECT, a stable extension ABI, new storage and parser foundations—but the migration window is now concrete. Builders can test real 2.0 alpha clients before the projected October release. - Status: Active - Published: 2026-08-26T06:12:03+12:00 - Updated: 2026-09-04T10:14:01+12:00 - Categories: Web Development, Cloud & Infrastructure, Developer Tools, Databases & Storage - Tags: client-server databases, database extensions, DuckDB, DuckDB 2.0 - Canonical HTML: https://beyondthe.news/dossiers/duckdb-2-preview-client-server-stable-extension-abi ## Latest material change Moves DuckDB 2.0 from early preview into feature freeze/alpha testing. DuckDB has branched v2.0-cyanoptera, made Python/CLI and core extensions installable as alphas, and now targets stable release in mid/second-half October. ## What changed DuckDB’s September 2 update moves v2.0 from an early preview into release stabilization. The project branched `v2.0-cyanoptera` from main, marking a feature freeze while work shifts to testing and bug fixing, with stable v2.0 projected for mid-to-late October. Python and CLI alpha builds are already installable, core extensions including `httpfs`, `ducklake`, `iceberg` and `spatial` are available in the alpha stage, and community extensions can test against the 2.0 branch using `ref_next`. The underlying architectural changes remain the same: Quack/CONNECT adds a native remote-execution path, v2.0 introduces a new storage format and PEG parser, and the reworked C API is intended to provide a more stable ABI for extensions. ## Why it matters DuckDB 2.0 is no longer just a roadmap for a different deployment model; builders can now run representative workloads against installable alpha clients while the feature set is frozen. That creates a short, useful compatibility window before stable release for teams that embed DuckDB, maintain extensions or are evaluating its new client/server path. The trade-off remains migration risk: the alpha is explicitly not production-ready, and the new storage, parser, extension and remote-execution surfaces still need real-world testing before October. ## The architecture is frozen enough for serious compatibility testing Branching `v2.0-cyanoptera` marks feature freeze. DuckDB says development on that branch is now focused on testing, bug fixing and stabilization rather than adding another wave of major features. That makes failures found against current alpha builds much more useful signals for the eventual stable release. ## Python and CLI users can install 2.0 alpha builds now DuckDB has made command-line and Python alpha clients directly installable, and plans to move more clients across as the release stabilizes. The project explicitly says these builds are not production-ready; their purpose is to expose different environments and workloads to the new engine before general availability. ## Quack and CONNECT still make 2.0 an architectural release The Quack protocol and CONNECT statement let DuckDB processes serve databases over a network and route work to remote DuckDB, PostgreSQL and MySQL systems. DuckDB says Quack will move to 1.0 in v2.0 with higher query throughput and better compatibility, expanding the embedded engine toward persistent shared-service use cases. ## The extension ecosystem is being pulled into the release test Core extensions including `httpfs`, `ducklake`, `iceberg` and `spatial` are already available for alpha testing. Community extension maintainers can provide a `ref_next` commit so their projects build against the v2.0 branch before release, which gives the ecosystem a concrete path to catch ABI and compatibility problems before users upgrade. ## Storage, parsing and ABI changes still deserve migration discipline DuckDB 2.0 changes the default storage format, replaces the PostgreSQL-derived parser with a PEG-based parser and introduces a reworked C API with a large intended stable ABI surface. Teams should therefore test representative database files, SQL and extension binaries now rather than assuming a major-version upgrade will behave like an ordinary point release. ## Key details - DuckDB branched `v2.0-cyanoptera` on September 2, marking feature freeze for v2.0. - The project is targeting the stable DuckDB 2.0 release for mid-to-late October 2026. - Python and CLI clients are already available as alpha builds. - DuckDB says the alpha clients are explicitly not production-ready and asks users to report reproducible failures. - Core extensions including `httpfs`, `ducklake`, `iceberg` and `spatial` can already be tested in the alpha stage. - Community extensions can use `ref_next` to test against the v2.0 branch before final release. - Quack is expected to move from 0.x to 1.0 in v2.0 with higher throughput and better compatibility. - The broader v2.0 release still includes a new storage format, PEG parser and reworked C API/stable-ABI work. ## Builder takeaways - Install the alpha in a disposable environment and run representative SQL, database files and extension workloads before the October release window closes. - Do not replace production DuckDB with the alpha; DuckDB explicitly says the current builds are for testing rather than production use. - If you maintain an extension, add and validate a `ref_next` path now so incompatibilities are found before v2.0.0 becomes the default target. - If Quack/CONNECT could simplify a shared-service architecture, test concurrency, failure behavior and operational assumptions against the alpha rather than extrapolating from the embedded deployment model. - Record parser or storage regressions with small reproducible cases; the project is explicitly in a bug-fixing phase where those reports can still affect the stable release. ## What to watch - The final v2.0 release date and complete migration/breaking-change notes. - Which additional language clients move onto the 2.0 alpha branch before release. - Quack 1.0 authentication, concurrency, durability and operational behavior under realistic deployments. - Extension compatibility results as community packages begin testing with `ref_next`. - Whether custom signed extension repositories land in the stable release and with what trust/key-management controls. - Real-world compatibility reports for the new storage format and PEG parser. ## Uncertainties - The stable release is projected for October but the exact date can move as testing finds issues. - Alpha clients are deliberately unstable and are not evidence that every v2.0 feature or extension is production-ready. - The custom extension repository feature was previously described as work in progress and its final v2.0 status remains to be confirmed. - A stable ABI reduces extension rebuild pressure only for APIs covered by that stable boundary; extensions using unstable internals may still need version-specific work. ## Sources - [Try DuckDB v2.0-alpha](https://duckdb.org/2026/09/02/try-duckdb-20-alpha.html) — DuckDB · official engineering blog · 2026-09-02T00:00:00+12:00. Primary source for feature freeze, alpha installation, extension testing and the projected October release window. - [A Preview of DuckDB v2.0](https://www.duckdb.org/2026/08/17/duckdb-20-highlights) — DuckDB · official engineering blog · 2026-08-17T00:00:00+12:00. Primary overview for client/server mode, CONNECT, storage/parser changes, stable C API and custom extension repositories. - [DuckDB v2.0: Your Database Deserves a Better Parser](https://duckdb.org/2026/08/20/duckdb-20-peg-parser) — DuckDB · official engineering blog · 2026-08-20T00:00:00+12:00. Primary detail on the PEG parser, compatibility goal and runtime-extension API. - [Release Cycle](https://duckdb.org/docs/lts/dev/release_cycle) — DuckDB · official documentation. Background on stable versus unstable extension APIs and release coupling.