DuckDB previews v2.0 plan to stabilize Quack server mode

Why it matters

DuckDB's founders are expanding the database into shared production workloads, creating a larger support market while putting its defining simplicity under pressure.

Mark Raasveldt (@mraasveldt) and Hannes Muehleisen (@hfmuehleisen), the researchers who created DuckDB, previewed the planned DuckDB v2.0 on August 17, outlining a client-server mode intended to expand the analytical database beyond the embedded architecture that defined it. The release, code-named Cyanoptera, is planned for fall 2026 and has no exact launch date. (duckdb.org)

The pair began DuckDB as a research project at Amsterdam's Centrum Wiskunde & Informatica, aiming to put a fast analytical SQL engine directly inside applications and data-science tools. Muehleisen remains a senior researcher at CWI and is CEO of DuckLabs; Raasveldt, DuckLabs' CTO, wrote his doctoral work around the intersection of relational databases, machine learning and analytics. Their original thesis removed the network protocol and operational machinery that came with conventional database servers. (ducklabs.com)

The v2.0 plan bends that thesis in response to how people are actually deploying DuckDB. Users have repeatedly asked for multiple processes and remote clients to share a database, a pattern the in-process design could not handle cleanly. Raasveldt and Muehleisen are addressing that constraint with the Quack extension, which implements DuckDB's native remote protocol, and a planned CONNECT statement that routes queries to another DuckDB process. (duckdb.org)

A concession built into the product

DuckDB's appeal came from avoiding a server. Developers could install a library, open a file or in-memory database, and run analytical SQL within Python, R, JavaScript or another host application. That made DuckDB useful for notebooks, local data processing and software that needed an embedded query engine without a separate service to deploy.

The same design created a hard boundary around multi-process writes. DuckDB can run concurrent transactions and multiple writer threads within one process, using multiversion concurrency control and optimistic concurrency control. Its current documentation says writes from multiple processes rely on Quack, which remains beta in the available 1.5 series and is expected to mature with v2.0. Conflicting updates to the same rows can still produce transaction errors. (duckdb.org)

Quack places one DuckDB process in charge of the database and lets remote clients attach over the network. A client can issue CONNECT, run SQL on the server and stream results back. The same statement can target PostgreSQL and MySQL, with DuckDB's optimizer pushing SQL to those systems instead of first copying their tables across the network. (duckdb.org)

That changes DuckDB's practical role. A tool that was commonly embedded in a notebook or application process can also sit behind long-running services. The founders are pairing the protocol with expanded metrics, logs and observability, acknowledging that a persistent shared database needs a different operating surface from a local analytical library. (duckdb.org)

The production bet

The server push also fits the economics of DuckLabs, the founder-owned operation that maintains DuckDB and sells commercial support, advisory work and feature prioritization. DuckLabs says it has more than 30 engineers and researchers in Amsterdam and remains independent of venture capital. Its roadmap says revenue comes from support and paid feature work, while the nonprofit DuckDB Foundation governs the open-source project. (ducklabs.com)

More production deployments give DuckLabs a wider market for those services. Networking and multi-user operation move DuckDB closer to workloads where teams pay for reliability guidance, architecture reviews and support agreements. DuckLabs said in May that DuckDB was seeing more than one million downloads a day, though it has not published revenue or customer figures alongside that adoption claim. (ducklabs.com)

The approach differs from handing the project roadmap to outside investors. DuckLabs says the original creators retain ownership, while commercial collaborations fund work on the MIT-licensed core. That structure leaves Raasveldt and Muehleisen responsible for managing a delicate expansion: they can pursue the production use cases users want while keeping the local, low-operations experience that drove DuckDB's adoption. (ducklabs.com)

Quack also changes DuckDB's boundary with managed products built around the engine. MotherDuck, a separate commercial service built around DuckDB, already provides managed multi-user operation. DuckDB v2.0 is expected to give users an open-source native route to shared remote operation, while users running Quack themselves will remain responsible for the surrounding deployment and operational work. (duckdb.org)

V2.0 reaches deeper than networking

The planned server mode leads a preview that Raasveldt and Muehleisen say covers more than 10,000 commits since DuckDB v1.5 shipped in March. The v2.0 plan includes a new default storage format, a PEG-based SQL parser, a broadened stable C API, triggers, asynchronous I/O and selected breaking changes. (duckdb.org)

The stable C API addresses a recurring cost for extension developers. Many DuckDB extensions have depended on an unstable C++ interface and needed rebuilding for each release. V2.0 is designed to let developers compile an extension once against a versioned API and keep the binary working across subsequent DuckDB versions. DuckDB already operates a Community Extensions repository for third-party extensions, but the project says it does not vet submitted code or guarantee that those extensions are safe. (duckdb.org)

For semi-structured data, the VARIANT type introduced in v1.5 is set to gain direct storage execution, Parquet reading and writing, scan pushdown and new functions for inspecting and filtering nested values. DuckDB stores the detected structure in a columnar representation instead of treating every value as a JSON text blob, an approach aimed at logs and other records whose schemas change over time. (duckdb.org)

Asynchronous I/O targets another growing DuckDB workload: querying Parquet and other files in object storage. DuckDB says the planned I/O layer separates network request concurrency from query-processing threads, allowing more remote reads to proceed simultaneously. The work covers Parquet first, with CSV, DuckDB files and asynchronous Parquet writes also included in the preview. (duckdb.org)

The preview also describes partial aggregate pushdown below joins, reuse of redundant aggregations, a rewritten recursive CTE engine and the ability for aggregations to spill to disk when they outgrow memory. (duckdb.org)

The test begins after the preview

DuckDB v2.0 has not shipped. The release calendar lists v1.5.5, released July 22, 2026, as the latest published version and gives v2.0 only a fall window. Preview builds contain much of the announced work, and the maintainers warn that details can change before release.

Quack's planned graduation from beta will carry the largest strategic burden. Raasveldt and Muehleisen spent years proving that an analytical database could disappear inside another process. V2.0 asks DuckDB to remain that small, portable engine while also serving remote clients, concurrent writers and long-running production workloads. The server feature grew from user pressure, and its success will depend on whether DuckDB can absorb the operational demands without making the embedded experience harder.