DuckDB v2.0 preview targets a stable release for its Quack server mode

DuckDB co-creators Mark Raasveldt and Hannes Mühleisen previewed DuckDB v2.0 on August 17, with the release targeted for fall. The update is set to stabilize the Quack client/server protocol, add a CONNECT statement, introduce a new storage format, and give extension authors a stable C API.

The release has not shipped, and its most consequential feature is not ready for production yet. DuckDB's Quack documentation schedules v2.0.0 for September and still describes Quack in v1.5.3 as experimental, with its functions and implementation subject to change.

For teams already embedding DuckDB, DuckDB server mode is an additional deployment path. Existing in-process use remains available, while Quack can put the same engine behind a network endpoint for several clients.

Quack adds a server without replacing embedded DuckDB

Quack starts inside an existing DuckDB session with CALL quack_serve('quack:localhost', token => 'analytics-team-token');. The server exposes the full SQL surface, including read and write access to every table the session can see. A remote client can attach it as a catalog, then send reads, writes, DDL, and transactions to it. The new CONNECT statement can route a session to a remote target, and the preview describes pushdown support for PostgreSQL and MySQL.

The default security boundary is narrow. Quack generates or accepts an authentication token, then its quack_nop_authorization callback allows every query from an authenticated client. Operators can replace the authentication and authorization hooks with scalar functions or SQL macros through quack_authentication_function and quack_authorization_function.

DuckDB's security guide shows why the replacement matters. Its illustrative read-only macro accepts queries beginning with SELECT, FROM, WITH, or EXPLAIN. A query beginning with WITH can still contain an INSERT, so DuckDB warns that the regex is not production-grade enforcement. It recommends inspecting the parsed statement type or attaching the database read-only. Non-local Quack servers also require allow_other_hostname => true, and DuckDB recommends putting them behind a TLS-terminating reverse proxy.

Preview builds let teams test most v2.0 features now, while Quack's production contract remains unfinished.

The stable extension API targets rebuild churn

DuckDB extensions currently tend to be compiled for a specific DuckDB version. The project can select the correct binary automatically, but extension maintainers still need to publish new builds as DuckDB changes.

The DuckDB stable extension API in v2.0 is generated from a versioned specification in PR #24135, covering duckdb.h, duckdb_extension.h, and the extension ABI. DuckDB says an extension can be built once and keep working indefinitely. The project has not demonstrated that promise across releases yet because v2.0 has not shipped.

The preview also adds CREATE EXTENSION REPOSITORY for self-hosted extensions. An organization can pin RSA signing keys to a repository definition, compare their SHA-256 fingerprints out of band, and supply a public key directly instead of trusting a network fetch.

DuckDB is also preparing to make its PEG-based SQL parser the default. The parser is experimental and disabled by default in v1.5, where it can be enabled with CALL enable_peg_parser();. It offers better error suggestions and allows extensions to add syntax to the grammar, although one commenter in the Hacker News discussion asked for documentation aimed at extension authors.

Storage migration still lacks its release notes

DuckDB calls the breaking-change set small and names two items: storage format v2.0.0 and the completed lambda syntax transition. The old x -> x + 1 form is disabled by default in v2.0 in favor of lambda x : x + 1. DuckDB's lambda documentation says v1.5 is the last release enabling the old form without an explicit setting, and v2.1 will remove the compatibility flag.

The DuckDB storage format change adds buffer-managed ART indexes, lazy column metadata loading, and DICT_FSST compression by default.

What is missing is the exact migration path for existing database files. Until DuckDB publishes the release notes, teams cannot tell how much preparation an upgrade will require or what rollback will look like.

Quack targets a familiar concurrency gap

The visible r/programming discussion was positive but thin. One commenter wanted better concurrency support. Another said Go's CGO requirement makes performance monitoring harder, then clarified that the problem involves reliance on Linux libraries.

The HN thread supplies the other side of the concurrency question. A developer running one DuckDB database per tenant said Quack was relaxing the sharp edges around concurrency. In a later comment, the same commenter said the beta protocol essentially fixes the cross-process constraint that prevents a separate reader and writer from opening the same file. It is one operator's assessment, not a general concurrency guarantee.

The preview confirms that embedded use remains while server deployment and more durable extension interfaces become first-class options. Before a production rollout, teams still need the final Quack contract, storage migration instructions, and extension compatibility terms from the September release.