Hi Query Farm Friends,

I’ve published two new posts about the work behind Query Farm: cutting the wait before your first query when using WASM for DuckDB, and making remote data and functions easier to use from a browser.

DuckDB-WASM startup: from 6.8 to 2.3 seconds

Waiting several seconds for a SQL environment to open gets old quickly. In our multithreaded benchmark, Haybarn-WASM went from page load to six loaded extensions in 2.3 seconds, down from 6.8 seconds in an earlier build. Memory usage with those extensions loaded also fell from 604 MB to 499 MB.

The post follows the time into Emscripten’s linker, thread restarts, and extension downloads. It also introduces prefetchExtensions(), which downloads, hashes, and compiles extensions in parallel before you load them.

If you use DuckDB-WASM, we cover the package swap to Haybarn-WASM and the extra setup call that delivers the full improvement. We’ve also submitted fixes upstream to DuckDB-WASM and Emscripten.

Read the startup performance breakdown →

Why we built VGI instead of waiting for Arrow Flight 2.0

Building Airport, our DuckDB extension for Arrow Flight, taught us a lot about catalog discovery, remote functions, and the difficulty of bringing Flight into a browser.

Those lessons led to VGI-RPC, which carries typed calls and Arrow batches over ordinary HTTP, and VGI, which defines catalogs, functions, and how they execute across query engines.

This post explains the design decisions, where ADBC and Quack fit, and the tradeoffs we accepted—including why workloads that need independent streams in both directions may still be better served by Flight.

Read the thinking behind VGI →

Thanks for reading and using Query Farm products!

Rusty
Query Farm