FAQ for Quack

Quack allows DuckDB to connect to a DuckDB server through the quack: protocol. You can think of Quack as a Remote Procedure Call (RPC) protocol for DuckDB. Quack enables DuckDB instances to talk to each other, effectively turning DuckDB into a client-server database management system, where both the client and the server are DuckDB instances.

Mallard ducks communicate by quacking, so it's only fair that DuckDB instances communicate through the protocol quack.

Quack can be beneficial in a number of scenarios, including the following:

• You need concurrent read-write access to the same DuckDB database.
• Your data is on a server and you want to move the computation as close to the data as possible.
• You have a powerful server that can process the data but would like to see the results on your local computer.
• And many more – we are excited to see what the community comes up with.

Yes. DuckDB with Quack can handle a few thousand writes per second on a server with 8 CPUs and 32 GB RAM. See the benchmarks in our announcement blog post.

Yes, DuckDB as an in-process database will continue working just as it did before, and we will treat the in-process deployment model as a first-class citizen in the DuckDB ecosystem.

Please follow the installation instructions and the documentation.

Quack uses HTTP v2.0 for communication. This allows Quack to work in environments with firewalls, load balancers, etc. You can provide your own encryption – see the “Reserve Proxy” guide.

Yes, Quack is available in DuckDB v1.5.2 as a beta release. To install and load it, run:

INSTALL quack FROM core_nightly;
LOAD quack;

Yes, we designed Quack to be a high-performance protocol for both bulk operations and small changes. We worked on minimizing the number of round-trips required. See the benchmarks in our announcement blog post.

Please consult the Quack documentation's Security page and the Securing Quack with a Reverse Proxy page.

Yes. By default, you can use all SQL features of the remote DuckDB server. It is possible to limit these features using custom authorization functions.

Currently, DuckDB with Quack does not support distributed query processing.

Please consult the DuckDB FAQ's “I would like feature X to be implemented in DuckDB. How do I proceed?” entry. If you think a feature is missing from Quack, please start a new discussion in the main DuckDB repository.

Not yet. Quack is currently in a beta state. You can use Quack for prototyping but it is still in development, and breaking changes are expected to happen. These may include the protocol, function names and default settings. We expect Quack to mature over the next few months and plan to release it as a stable protocol as part of DuckDB v2.0 in September 2026.

The code is available in the duckdb-quack repository. You are welcome to open issues and propose new features through a discussion in the main DuckDB repository.

Please submit an issue in the duckdb-quack repository.

There are several third-party solutions providing remote access to DuckDB (e.g., the airport extension and GizmoSQL using the Arrow Flight Protocol). Quack is a clean slate implementation from the core DuckDB team. Quack, in the spirit of the DuckDB project, does not have any third-party dependencies.

Quack is a remote protocol for DuckDB that enables client-server use of DuckDB. DuckLake is an open lakehouse format supported by different data management systems, including DuckDB itself but also Apache Spark, Apache DataFusion and Trino.

Quack and DuckLake share a few similarities:

• Both are available in DuckDB as an extension.
• Both of them unlock the “multiplayer DuckDB” experience by allowing multiple writers to access the same database.

However, Quack and DuckLake are also fundamentally different.

Relation to DuckDB:

• Quack is exclusive to DuckDB as it allows DuckDB processes to communicate.
• The DuckLake format is not exclusive to DuckDB: they can be created, read and updated via different clients.
• Storage:
  • Quack allows you to run a DuckDB server that uses DuckDB's native database format for storage. This allows you to scale up to a few terabytes.
  • DuckLake stores the data on object storage, which allows it to store huge, potentially petabyte-scale datasets.
• Setup:
  • The setup of Quack only requires installing the Quack extension on both the client and the server.
  • DuckLake requires a central catalog database. A typical DuckLake setup includes object storage (where the data is stored in Parquet format) and a catalog database.

Quack and DuckLake can be combined in different combinations. For example, if you have a huge database or need time travel capabilities, consider using DuckLake as that is served through a DuckDB instance through Quack.

Not yet, but we are working on it!

Quack is a protocol that allows remote access to a DuckDB server. It's an MIT-licensed open-source solution that you can run in a self-hosted environment or in the cloud.

MotherDuck provides a fully managed database-as-a-service in the cloud. As such, it also allows remote access among other features of a managed database (central user management, backups, etc.) and other advanced features such as dual execution (currently not supported by Quack). MotherDuck uses DuckDB both on the client side and on the server side but it employs its own protocol for communication. When building Quack, we incorporated lessons from the MotherDuck team learned into building our protocol.