DuckDB’s Quack Protocol Solves the Problem I Kept Working Around

Why multi-process writes may finally stop sending me back to Postgres or folders full of Parquet files

It seems like every other week Jared joins our daily standup and tells us about a new DuckDB affiliated product. He's told us about DuckLake, MotherDuck, regular ducks he saw on a walk with his kids (it turns out you can just take those, they're free!). Really, the list goes on, but most recently, and, I think the most exciting one yet, is the new Quack protocol. If you've tried to use DuckDB outside of a plain notebook or simple script before, you've probably noticed that it doesn't support writing from multiple connections. Quack solves that issue, making DuckDB an even stronger player in the DB space, especially against PostgreSQL which is big and comparatively slow, especially for geospatial work (turns out elephants can speed walk faster than ducks can run, but I digress).

The Problem (and the Workarounds)

The DuckDB concurrency docs are honest about the situation. One process can read and write, or many processes can read but none can write. Within a single process, threads coordinate through multi-version concurrency control (MVCC) and life is good. But two separate processes that both want to write? No can do.

I've run into this enough times to be a little tired of it. I use DuckDB when I want things to be fast and when I want fast, I'm usually running in parallel and I want to write to the same DB as each step completes. It's something Postgres has no problem with, but I've had to use some workarounds with DuckDB. If my data is small enough, I can just return it back to the main process and write it out all at once, but if it's that small, I usually do it in one thread. Another solution is to write to a partitioned csv or parquet format and split the threads based on the partition. It works well enough and DuckDB can use the output as the backend directly, so most people would be happy.

But every time I do it, I'm doing two things I don't really want to be doing. I'm giving up transactions, because there's no atomic "all of these writes succeeded together" across separate parquet files. And I'm pretending that the union of a bunch of files is the same thing as a database, which is fine until I need to update a row, or delete something, or do anything other than append. Parquet files are immutable once written, so changing a single value means rewriting the whole file it lives in, or bolting on DuckLake to manage updates as a separate layer, which is great but is also several more pieces of infrastructure to look after. CSVs aren't immutable in the same way, but they're so much slower to read and write at any real size that I'd rather take the parquet headaches.

None of these are bad. They're just things I shouldn't have to do for what is, fundamentally, "let two scripts write to the same database."

What is Quack?

Quack lets one DuckDB instance act as a server, and other DuckDB instances connect to it like it's a regular local database. The overview docs describe it as an HTTP-based remote protocol that transmits DuckDB commands over plain HTTP or HTTPS. The practical experience is that you have one DuckDB file somewhere, and everyone else gets to talk to it.

You start the server with one SQL call.

CALL quack_serve('quack:localhost');

And from somewhere else, you attach to it like you would any other DuckDB database.

ATTACH 'quack:localhost' AS remote;

That's it. Both sides are full DuckDB, so you don't have to learn a new dialect of SQL, you don't lose any types, and you don't trade off the things that made DuckDB nice in the first place. The transport is plain HTTP, which means it plays well with all the boring things like reverse proxies, TLS, and load balancers, which should be an easier swallow for network IT.

Why I'm Excited About This

The thing I like most about Quack is that it doesn't ask me to change my mental model. Going back to the parallel jobs example, I don't have to design a queue, or partition writes into folders, or stand up a separate database that I also have to back up. Each parallel worker writes, the scheduled job writes, my notebook reads, and they all see the same data at the same time.

The announcement post benchmarks show over 5,000 transactions per second with concurrent clients, which is more than enough for almost anything I'm building for an internal team. If I had a workload that really needed tens of thousands of writes per second I'd reach for something else, but that's not most of what I do, and I suspect it's not most of what you do either.

The other thing I like is that it lets me keep starting projects small. I have a bad habit of starting things with a single Quarto doc and a flat file, then a coworker wants in, then it's a real thing, then I'm rewriting it as a real database app. Quack means I can grow the multi-user version of the project without throwing away the small version it started as.

It's worth saying that Quack is in beta right now, shipping with DuckDB v1.5.3, with a stable release expected with DuckDB v2.0 in Fall 2026. I wouldn't put it in front of paying customers tomorrow. But for internal tooling, dashboards, small-team apps, and the kind of thing where I used to reach for a folder full of Parquet files and a hope and a prayer, it's already doing exactly what I want.

If you've spent any time building around DuckDB's single-writer limit, give Quack a look. I think you're going to be happy you did.

Gus Lipkin

Data Scientist

Lander Analytics

---

Subscribe to our Substack and below to our monthly emails for practical AI strategies for your organization: what to build, what to avoid, and how to make systems reliable in the real world.

Work with us: If you want help identifying the right first workflow, building a permissioned knowledge base, or training your team to ship responsibly, reach out at info@landeranalytics.com.

About the author: Gus Lipkin is a Data Scientist at Lander Analytics, where he writes software for data science practitioners and consumers.