DuckDB Quack Protocol: DuckDB Can Now Run as a Server

Wed, 13 May 2026 00:00:00 +0000

Wait, Isn’t DuckDB “Embedded”?

Yes. Since its launch in 2019, DuckDB has prided itself on its in-process architecture — no client, no server, no communication protocol, just direct API calls. It’s perfect for data science, Python notebooks, and embedded analytics.

But there’s been one pain point: what happens when multiple processes want to write to the same database file?

Think about:

Multiple telemetry collectors inserting into the same DuckDB
A dashboard querying the same tables simultaneously
Two processes writing at once → 💥

Before Quack, your options were: build a custom RPC service, use the Arrow Flight SQL protocol, migrate to MotherDuck, or (sigh) switch to PostgreSQL.

On May 12, 2026, DuckDB finally solved this. Meet Quack.

What is Quack?

Quack is the communication protocol between DuckDB instances. What do two (or more) ducks do when they want to talk? They quack! So naturally, the protocol DuckDB instances use to talk to each other is called… Quack 😄

In a nutshell: DuckDB now runs as a server, and other DuckDB instances connect as clients to read and write data.

Key features:

HTTP-based — no proprietary protocols, firewall-friendly
Multi-client concurrent writes — finally solves the long-standing pain point
Token-based authentication — simple but effective
Arrow data format — zero-copy, high performance
Full query and DML support — not just read-only

Quick Start

You need two DuckDB instances (v1.5.2+) with the Quack extension:

Server (DuckDB #1)

INSTALL quack FROM core_nightly;
LOAD quack;

CALL quack_serve(
 'quack:localhost',
 token = 'super_secret'
);

CREATE TABLE hello AS
 FROM VALUES ('world') v(s);

Three lines. DuckDB is now a server, listening on quack:localhost, ready for clients.

Client (DuckDB #2)

INSTALL quack FROM core_nightly;
LOAD quack;

CREATE SECRET (
 TYPE quack,
 TOKEN 'super_secret'
);

ATTACH 'quack:localhost' AS remote;
FROM remote.hello;

Output:

world

The client queries the server’s table as naturally as a local table.

More Than Queries — Writes, DDL, Everything

Quack isn’t read-only. Clients can write too:

-- Write to remote
CREATE TABLE remote.hello2 AS
 FROM VALUES ('world2') v(s);

-- Verify
FROM remote.hello2;

Output:

world2

Full CRUD, DDL, and transactions — everything works over Quack.

Who Should Use This?

Quack unlocks use cases that were previously impossible with DuckDB:

Scenario	Before	After
Multi-process writes to same DB	❌ Crash	✅ Quack server + concurrent clients
Live dashboard + background writes	❌ Single process only	✅ One Quack server, N clients
Shared data across microservices	Custom RPC needed	✅ Native ATTACH syntax
Remote data analysis	SCP files around	✅ ATTACH remote instance directly
Centralized ingestion from edge devices	One file at a time	✅ Batch INSERT to one Quack server

How It Works Under the Hood

Client Server
 │ │
 │── HTTP POST ─────────→ │ (Query request, Arrow format)
 │ │
 │←── Arrow Stream ────── │ (Streaming response)
 │ │
 │── HTTP POST ─────────→ │ (Write request)
 │←── Affected Rows ──── │ (Row count)

Transport: HTTP + Arrow — not sockets, not binary protocols
Data format: Arrow — zero-copy, high performance
Auth: Simple secret token
Addressing: quack:host:port format

Compared to PostgreSQL’s wire protocol, Quack is lighter. Compared to Arrow Flight SQL, Quack feels more like DuckDB-native SQL.

Note: Quack is currently in the core_nightly repository, not a default extension yet. The DuckDB team calls this a “first version” with ongoing improvements.

Try It Yourself

Install DuckDB v1.5.2 and open two terminals:

Terminal 1 (Server):

duckdb -c "
INSTALL quack FROM core_nightly;
LOAD quack;
CALL quack_serve('quack:localhost', token = 'my_token');
CREATE TABLE events AS SELECT 1 AS id, 'test' AS name;
SELECT 'Server ready!' AS status;
"

Terminal 2 (Client):

duckdb -c "
INSTALL quack FROM core_nightly;
LOAD quack;
CREATE SECRET (TYPE quack, TOKEN 'my_token');
ATTACH 'quack:localhost' AS remote;
FROM remote.events;
"

If you see 1│test, congratulations — your two DuckDB instances just talked to each other via Quack!

Summary

Quack is a major milestone for DuckDB. It doesn’t negate the in-process architecture — for single-machine data analysis, that’s still DuckDB’s superpower. But when you need multi-process collaboration, remote access, or shared real-time data, Quack provides an elegant, native solution.

Simple to install. Feels like DuckDB. Powered by Arrow for speed. Fast when you need it, connected when you need it.

Original article: https://duckdb.org/2026/05/12/quack-remote-protocol

Concurrent Writes on DuckDB Lab