DuckDB’s new Quack extension adds an HTTP-based client-server protocol enabling multiple concurrent writers and cross-process DuckDB communication.
Key Takeaways
Quack runs as a DuckDB extension (INSTALL quack FROM core_nightly), available in v1.5.2; server and client are both plain DuckDB instances.
Built on HTTP with a custom application/duckdb MIME type using DuckDB’s internal serialization primitives, already battle-tested in WAL files.
Single round-trip per query after connection; bulk transfers benchmarked faster than PostgreSQL wire protocol and Arrow Flight SQL on same-AZ AWS m8g.2xlarge instances.
Auth uses a random token by default; both authentication and authorization callbacks are user-replaceable, including via plain SQL macros.
DuckDB-Wasm can speak Quack natively, enabling browser-to-server DuckDB connections without extra glue.
Hacker News Comment Review
Commenters debate what DuckDB “wants to be”; the strongest counter is that Quack is coherent: it mirrors how SQLite expanded scope without abandoning its embedded identity.
A precise technical note: “concurrent writers” in Quack means serialized writes on the server side, not true parallel write concurrency – the post does not clarify this.
Practical use cases cited include observability data pipelines (OTLP/Parquet), sensor ingestion with parallel read access via duckdb -ui, and small multi-user internal apps.
Notable Comments
@feverzsj: Points out Quack’s “concurrent writers” is likely serialized server-side – a key architectural limit the announcement omits.
