DuckDB 2.0 Just Got a Server—and a Catch

DuckDB earned its reputation as a powerful, file-first analytics database. Like SQLite, it runs embedded within an application, eliminating the need for a separate server setup. This design made it incredibly appealing for lightweight, in-process analytical workloads.

However, this embedded nature came with a significant catch: concurrency. Each application process maintains its own cached state of the database in memory. While efficient for a single process, this architecture means only one process can write to a database file at a time. DuckDB couldn't keep multiple processes' cached states in sync.

Imagine a team running several services, dashboards, and applications, all needing to access and update the same analytical data. With traditional DuckDB, they faced a dilemma: either build a complex sharing layer themselves to coordinate writes, or choose a different database entirely.

This bottleneck forced many to work around DuckDB's core strengths. Some users even resorted to running DuckDB inside PostgreSQLQL to achieve shared access. The very feature that made DuckDB so accessible—its embedded, serverless nature—became its biggest limitation for collaborative environments.

Quack, first introduced experimentally in May, gives DuckDB a front door. One DuckDB instance opens the database file and acts as the server. Other DuckDB instances connect to it over plain HTTP, sending their reads and writes. This allows multiple applications to interact with the database concurrently.

Crucially, the server remains the only process directly touching the database file. This architecture avoids the pitfalls of unrestricted multi-process file writing, where concurrent caches could lead to corruption. Instead, clients share access through a coordinator, ensuring data integrity while expanding accessibility.

DuckDB’s team noted that many users were already building custom wrappers or even running DuckDB inside PostgreSQLQL to achieve lightweight shared access. Quack, now a polished feature in DuckDB 2.0, provides a native, officially supported solution for this common use case. It allows developers to enable multi-client access without resorting to bespoke, often fragile, workarounds.

This new server capability doesn't change DuckDB's core identity as a file-first analytical database. It simply adds a robust, native option for coordinated access. For example, DuckDB can transfer 60 million rows between two machines in under 5 seconds using Quack, significantly outperforming PostgreSQLQL’s protocol, which took over 2.5 minutes for the same task. While tiny writes plateau around 5,500 per second with 8 threads, this is ample for several services sharing a dashboard.

Quack’s most striking demonstration involves data transfer speeds. In a Better Stack video, the DuckDB team sent 60 million rows between two machines in under five seconds using Quack. For comparison, the PostgreSQLQL protocol took over two and a half minutes (more than 150 seconds) for the same operation.

This benchmark highlights Quack’s advantage for analytical workloads. Unlike traditional row-oriented database protocols, Quack transfers native DuckDB column-vector payloads directly over HTTP. This bypasses the substantial overhead of converting column-oriented data into row-by-row formats, then back again, which is typical for many database wire protocols.

The speedup is significant for analytical transfers, where moving large datasets efficiently is crucial. While impressive, remember that this is a reported benchmark. Real-world performance can vary based on:

• Your specific workload
• Network conditions
• Hardware configurations
• Query shapes

For a deeper dive into how Quack achieves this, including its design principles, you can explore the official documentation on Quack: The DuckDB Client-Server Protocol. This protocol is a game-changer, but it’s essential to understand its specific strengths and limitations for your use case.

Quack excels at moving large analytical datasets, but it’s crucial to understand its limits for transactional workloads. Benchmarks show DuckDB server mode outperforming PostgreSQLQL for small writes up to roughly eight concurrent threads. Beyond that, performance levels off near 5,500 writes per second.

This ceiling exists because the DuckDB server, while enabling multiple clients, still relies on a single process to handle all file writes. Think of it as a single, highly efficient cashier serving many customers; they can only process so many transactions per second.

This architecture is perfect for shared analytics, dashboards, and services that benefit from a simple, central DuckDB hub, especially when fast bulk data movement is a priority. It streamlines data ingestion and complex queries across applications.

However, high-frequency transactional systems, where every write must be processed instantly and concurrently, will find this single-process bottleneck limiting. For those demanding OLTP (Online Transaction Processing) scenarios, PostgreSQLQL or another dedicated OLTP database remains the more appropriate choice. DuckDB 2.0 also includes other storage and query improvements, but Quack's design is the key consideration for concurrent writes.

What is Quack in DuckDB 2.0?

Quack is DuckDB’s client-server protocol. It lets client instances send queries and writes over HTTP to a DuckDB process that owns the database file.

Can multiple applications write to the same DuckDB database?

Yes. With Quack, multiple clients can send work to one server instance, which is the only process directly accessing the database file.

Does DuckDB 2.0 replace PostgreSQL?

No. DuckDB server mode suits shared analytics and modest write loads; PostgreSQL is generally a better fit for demanding, high-concurrency transactional workloads.

How fast is DuckDB Quack?

The video reports transferring 60 million rows between two machines in under five seconds. Small-write throughput reportedly levels off around 5,500 writes per second.