Quack Protocol: Client-Server Architecture for DuckDB

Allowing Client-Server Architecture over the network (TCP/IP with HTTP) for DuckDB, opening up new DuckDB Use Cases.

Quack, a protocol that turns DuckDB into a client-server database. True to DuckDB’s philosophy, Quack is simple and fast. You can set it up in seconds and it delivers high-performance remote access, turning DuckDB into a full-fledged general-purpose database system.

Note

Youtube linked below got replaced with new one: DuckDB-Quack announcement at AI Council - YouTube (better sound - i leave the one below, as they have timestamps to the exact point).
Slides are at hannes-muehleisen-quack-ai-council-2026.pdf.

Everything from DuckDB-Quack Announcement at AI Council 2026 - YouTube.

many community plugins:

# What it Solves: where Single-Node Processors Doesn’t Solve it

1
2

LOAD quack;
CALL quack_serve('quack:localhost');

That returns an HTTP URL, with the default authentication function in use. Use auth_token that clients need to connect. This token can also be set explicitly before starting (see Security).

There’s no server
There’s no separate server or client; they’re both DuckDB instances. Almost like a peer-to-peer network. But one will always be the one queried from, ergo server.

Other option: By default the server refuses to bind anything other than a local hostname. To listen on an externally-reachable address, do this instead:

1
2

LOAD quack;
CALL quack_serve('quack:0.0.0.0:9494', allow_other_hostname => true);

Quack endpoints use the quack: URI scheme and 9494 as the default port. Some examples:

Latest at Quack Remote Protocol – DuckDB.

• = You now locally, also just spawn up a server in your browser with Webassemly, and connect with your local client in the terminal to that server. Really nice DuckDB Use Cases opening up!

To attach a local database via HTTP, simply run:

1
2
3

ATTACH 'quack:localhost' AS remote_db (
    TOKEN 'MY_QUACK_TOKEN_01234567890ABCDEF'
);

Attaching remote databases uses HTTPS by default. To override on a plain-HTTP remote:

1
2
3
4

ATTACH 'quack:remote.com' AS remote_db (
    TOKEN 'MY_QUACK_TOKEN_01234567890ABCDEF',
    DISABLE_SSL true
);

Once attached, remote tables look and behave like local ones:

1
2

CREATE TABLE remote_db.t AS FROM range(10) r(i);  -- DDL on remote
INSERT INTO remote_db.t VALUES (42);              -- remote writes

The attached catalog also exposes a query table macro for ad-hoc SQL scoped to that attachment:

1

FROM remote_db.query('SELECT 42');

All extensions and all SQL statements from DuckDB on the remote server just work.

• ! You can query in two ways - the first one below is much slower, as it will fetch and transfer the whole table over the network first, and then do the limit - the second one does the limit on the server first, and only loaded/transfered 10 rows.

This is classic query pushdown. With Quack, you choose where computation should happen (on your client or on the server).

1

CALL quack_stop('quack:localhost');

They use TCP/IP and HTTP(S), as they couldn’t use anything else as DuckDB servers WebAssembly and serves over HTTP. But it turned out, because of YouTube and the world running on the web, it was also the fastest. Very counter intuitive, Hannes Mühleisen said.

simple architecture with in layers:

1. TCP/TP
2. HTTP/(S)
3. duckdb::Serializer
4. duckdb::Message

DuckDB already has a serializer, so they can use it.

The Arrow team has a similar protocol, called Arrow Flight RPC/protocol? DuckDB used the GizmoSQL — High-Performance SQL Server.

• The challenge, the authentication: they have a token one built in, but you can do your own with extensions.
• Next challenge: Authorization: who has access to what

It tries not to solve everything, but gives you the protocol to do something exciting

16 million rows - postgres (blue) took 3 minutes, quack 5 seconds

Compared to Arrow and Postgres

They also plan to have an auto replica, so the secondary is automatically up to date

Hannes view is this - with Postgres being general purpose, not OLTP.

TigerBeetle being the OLTP - caveat from my side, TigerBeetle does only financial transactions and is a very niche use case. So having it as OLTP is correct, but not representative of the whole category.

Today, with the Quack protocol, Hannes thinks they are moving further toward the middle as a general database.

Also, a side note: OLAP is much more than DuckDB. DuckDB has multiple DuckDB Use Cases, but massive OLAP is not one of them; it’s more single-node, as Hannes said earlier, so it would need Modern OLAP Systems.

Hannes Mühleisen demos how to install from scratch and play around and fetch 1 million rows from Amsterdam to us-east-1 in a 4 seconds with the quack and duckdb auto scale out that hiddes the and limit the huge network latency that us have:

1 mio:

100k rows:

Quack w/ Hannes Mühleisen (DuckDB)

You can just attach DuckLake and specify it through the Quack protocol, where the catalog (DuckDB in this case) is living, and have a Open Data Catalog with DuckDB through Quack:

Shown here by Hannes Mühleisen Before you continue to YouTube

• quack-on-demand: Starlake integration: Production-grade Arrow Arrow Flight SQL gateway in front of DuckDB Quack + DuckLake. Multi-tenant pools, pluggable auth (DB/JWT/OIDC), table-level ACLs, role-aware routing, and a live admin console
  • Starlake.ai | A.I. Powered Data Integration Platform

• replace simple token-based built-in with OAuth: GitHub - DataZooDE/quack-oauth: Extensions providing OAuth and OpenID primitives for authentication and authorization for the DuckDB quack server. · GitHub

• Usually, database clients are quite dumb; you can send a query and retrieve data. But with Quack, you could aggregate, you could build a whole ETL job, aggregation, or any business logic inside it. Reminds me a little bit about Analytics API, and how this could be improved by a living business logic inside Quack or app logic, similar what we did with the Metadata Store and Modern ValueStore.
  • Pollmd
• Duckle

New since 2026-05-12: Quack Remote Protocol – DuckDB

It’s funny how the pendulum between client and server swings forth and back.

Back in the days, when PHP was the ultimate web language, everything had to run on the server, every variable calculation. With the Small Data ecosystem and a local-first approach, it’s great to have the option to run server-side too.

I tried the boundaries and created something I wanted for a long time, a small, minimal poll service that I can just add to my markdown newsletter. I use a simple duckdb file on the server and a little Go to store, and use Quack for serving as a server for queries and results. Works pretty well! I call it Pollmd, just in case you want to check it.

Origin: DuckDB-Quack Announcement at AI Council 2026 - YouTube by Data Council (Conference)