In early 2026, the DuckDB team released Quack, an experimental database communication protocol that lets DuckDB instances on different servers read and write each other's data over HTTP. It is not distributed query processing in the traditional sense. You cannot join a table on server A to a table on server B in a single optimized plan. But you can fire SQL at a remote database and get results back, which opens the door to coordinated, concurrent execution across multiple nodes.
To test this, a data engineer built Cluster-Duck, a trio of AWS EC2 instances running DuckDB with one node acting as coordinator. The goal was simple: validate whether Quack could handle parallel reads and writes across remote databases without collapsing into race conditions or inconsistent snapshots.
The Setup
Three t4g.nano instances, each with an 8GB gp3 volume, were provisioned via CloudFormation. Each server boots with a synthetic dataset of 10 million records generated directly inside its local DuckDB file. Worker 1 holds sales data, Worker 2 holds customers, and Worker 3 holds products. The data is never uploaded from the engineer's laptop or copied between servers. Each server reads its WorkerIndex tag from the EC2 Instance Metadata Service to know which dataset to generate.
Quack listens on port 9494 by default. Authentication tokens are generated by a Lambda custom resource at stack creation time and stored as SecureString parameters in AWS Systems Manager Parameter Store. The Python coordinator source is embedded as a Base64-encoded archive inside the CloudFormation template itself, so the entire stack is self-contained.
How the Coordination Works
The coordinator validates each incoming SQL statement as a single query, wraps it in a QueryFragment, and labels it in order. It then creates one thread per fragment and initializes a threading barrier with the same number of participants. The barrier holds all threads until every fragment is ready, then releases them simultaneously.
Each thread opens its own local DuckDB connection, loads the Quack extension, attaches the target remote worker, and calls remote.query(). The fetchall() call materializes the result on the coordinator. After all futures complete, the coordinator records start offsets and durations, then presents the combined output.
This is not true distributed execution. Quack handles the remote transport; Python handles the synchronization, timing, and result collection.
Concurrent Reads in Practice
A simple test fires three count queries simultaneously:
The barrier releases all three threads together. Measured start spread is under 5 milliseconds, and each query completes in roughly 0.5 seconds. The results arrive independently but are presented in a single unified output.
A heavier test runs three complex analytical queries with window functions, CTEs, and ranking operations across the same datasets. Query durations range from 4 to 15 seconds, but the barrier still coordinates their start times with a spread of roughly 4 milliseconds. The slowest query dominates the wall-clock time, which is the expected behavior for embarrassingly parallel workloads.
Concurrent Writes and Snapshot Isolation
To stress the consistency model, the test fires 20 INSERT statements and 3 SELECT statements concurrently against the same sales table. Each INSERT is a separate autocommit transaction. The SELECT queries see consistent snapshots: they may see none, some, or all of the new rows depending on when they begin, but they never see half of an individual insert or a result that changes mid-scan.
The output confirms this. One read sees 4 new rows, another sees 13, and a third sees 16. The exact counts depend on transaction commit timing relative to snapshot acquisition, which is exactly the behavior DuckDB promises.
Cost and Caveats
The entire four-hour test costs approximately $0.12 in us-east-2, before free-tier credits. DuckDB and Quack are free. The t4g.nano instances are tiny. The engineer notes that Quack is explicitly experimental, with protocol changes expected, and should not be used in production.
Still, the test demonstrates a useful pattern. For workloads that can be decomposed into independent SQL fragments, Quack plus a thin Python coordinator provides a lightweight way to parallelize DuckDB across machines without building a full distributed database.