Yesterday, the DuckDB team announced Quack, a native client-server protocol for DuckDB. This is a big deal. After years of a clear "in-process or bust" stance, DuckDB now ships a first-party way to run as a server with multiple concurrent writers — and the benchmarks they published for both bulk transfers and small writes are genuinely impressive.
Congratulations to the entire DuckDB Labs team. Designing a database protocol from scratch in 2026, with no legacy to carry and the freedom to learn from everything that came before, is a rare luxury. They used it well.
A surprise — and a thank you
In the acknowledgements section of the launch post, the DuckDB team wrote:
"We also want to thank Philip Moore from GizmoSQL / GizmoData, who has blazed this trail for us already and shown that client-server DuckDB is a very worthwhile thing."
To say I was honored is an understatement. When we built GizmoSQL, the bet was simple: DuckDB is an extraordinary analytical engine, and there is real, growing demand to use it across processes, machines, and tenants — not only embedded inside a single one. Arrow Flight SQL gave us a way to deliver that with mature, battle-tested client tooling on day one. Seeing the upstream team validate the thesis by building their own native protocol means we got something fundamentally right.
Thank you for the kind words, and for the years of work that made any of this possible in the first place.
Where GizmoSQL fits
Quack is a fantastic addition to the DuckDB ecosystem, and we expect it to become a natural choice for many DuckDB-to-DuckDB workloads. The DuckDB world is bigger today than it was yesterday, and that's good news for everyone building on it — including us.
GizmoSQL was built around a complementary set of design goals, and those goals are exactly why it remains a strong fit for many production deployments:
Meet your existing tools where they are. Most enterprises run a stack of BI, ETL, notebook, and orchestration tools that already speak Arrow Flight SQL, JDBC, and ADBC. GizmoSQL plugs into that ecosystem on day one, with mature, battle-tested client libraries in nearly every language and a long list of off-the-shelf integrations.
One server, multiple backends. GizmoSQL runs on both DuckDB and SQLite. For embedded analytics, edge deployments, and workloads where SQLite's ubiquity and footprint matter, having a single server interface across both engines is a real operational win.
Production-grade by design. A lot of what makes something deployable in production lives above the wire protocol: authentication options like LDAP, OAuth, and SSO; row- and column-level authorization; multi-tenancy with per-tenant resource limits; audit logging; and observability. That's where GizmoSQL's enterprise edition lives, and where we'll keep investing.
Interoperability as a first principle. By building on Apache Arrow Flight SQL, GizmoSQL benefits from a standard that's actively evolving across the broader data ecosystem. Different protocols make different tradeoffs, and we think there's plenty of room for both — Quack for tight DuckDB-to-DuckDB integration, and GizmoSQL for connecting the wider world of clients to DuckDB- and SQLite-backed data.
Looking forward
A bigger client-server DuckDB world is good for us, good for DuckDB Labs, and — most importantly — good for users. More options means more workloads find a home, and more developers and analysts get to put DuckDB's engine wherever they need it.
We're already thinking about how GizmoSQL evolves alongside Quack, including the possibility of a future GizmoSQL that speaks Quack natively in addition to Arrow Flight SQL — so a single deployment can serve every client, regardless of which protocol they prefer. If that's interesting to you, get in touch.
Huge congratulations again to the DuckDB team. We're proud to have helped show the value of client-server DuckDB, and we're excited to keep building alongside them.
— Philip Moore
Founder, GizmoData