A DuckDB Distribution for Everyone.
Same SQL, same database files, same extension names — with signed builds, rebuilt extensions, and a faster object-store client on top. Free to use on a laptop, and reviewable enough to put in production.
Four guarantees
Drop-in compatibility
Same SQL, same APIs, same database files, same extension names. Adopting the distribution is not a migration.
Verified artifacts
Engine and extensions carry checksums, a detached GPG signature, and SLSA build provenance — checkable before anything runs.
Concrete install paths
npm, PyPI, crates.io, Maven Central, and GitHub Releases. Pick the channel you already use.
Safer defaults
The default catalog is the set DuckDB CI builds, minus third-party vendor code. Nothing autoloads that you did not ask for.
Install it, then it's deterministic
Pick the client you already use. Every artifact below is checksummed, GPG-signed, and carries SLSA build provenance, and the CLI checks the signature before anything lands on disk.
# Run it without installing anything, via npm
npx haybarn@rc
# ...or via PyPI
uvx haybarn-cli==1.5.5rc1ARM64 Windows is not built yet — the x86-64 build runs under emulation.
Every artifact is listed in SHA256SUMS, signed in SHA256SUMS.asc, and carries SLSA build provenance. All releases
pip install --pre haybarnThe package and import name are both haybarn. Because the API surface matches DuckDB’s, porting is a one-line change: import haybarn as duckdb.
npm install @haybarn/node-api@rcA drop-in for @duckdb/node-api — the import path is the only edit. Extensions can also be declared in package.json and loaded straight from node_modules.
cargo add [email protected]The crate follows its own version line rather than the engine’s, and has no stable release yet, so the version is required — a bare cargo add haybarn will not resolve.
<dependency>
<groupId>farm.query.haybarn</groupId>
<artifactId>haybarn_jdbc</artifactId>
<version>1.5.4-rc1</version>
</dependency>On Gradle: implementation("farm.query.haybarn:haybarn_jdbc:1.5.4-rc1"). The JDBC URL prefix is jdbc:haybarn:.
npm install @haybarn/haybarn-wasmThe public TypeScript API matches duckdb-wasm, so porting is a single import rewrite — plus the OAuth and worker bridges duckdb-wasm has no equivalent for.
The same SQL you already write
Nothing here is Haybarn-specific.
a5
is an ordinary DuckDB community extension — Haybarn rebuilds it, signs it with the
Haybarn key, and tracks its readiness for every release. Paste it into the CLI you
just installed, or press Try it in your
browser: that boots the Haybarn engine compiled to WebAssembly, right in this
tab, and resolves a5
from the same signed channel the CLI uses.
INSTALL a5 FROM community;
LOAD a5;
SELECT version() AS engine,
a5_lonlat_to_cell(-122.4194, 37.7749, 10) AS san_francisco;Nothing changes in your SQL. Four things stop being your problem.
Haybarn is the same engine, so switching costs you nothing. What you get back are the rough edges around it, already filed off.
Remote data arrives faster
Parallel range reads share one HTTP/2 connection instead of opening one each, and a file that changes mid-read costs you nothing instead of a wasted 16 MiB.
How it works →Installs stop drifting
Pin an extension version and the engine actually remembers it — or declare it in your lockfile and load it with no network at all.
How it works →Your tools connect
Power BI, DBeaver, Grafana and anything else speaking the PostgreSQL wire protocol connect and introspect instead of failing on a broken catalog join.
How it works →It works in the browser
Wasm extensions survive their first exception rather than dying on it, and can run a real sign-in flow from inside a Worker.
How it works →Measurements, settings, and what upstream does instead.
Opinionated, on purpose
Haybarn is built and controlled by Query.Farm, and that independence is the whole point. We can reach a different conclusion than the DuckDB project does, on our own timeline, when our experience and our clients' work tell us to.
Every change we ship started there. Moving object-store reads onto HTTP/2, widening the WebAssembly API surface until an extension could run a real sign-in, extending engine APIs so a pin actually holds — none of these are things upstream got wrong. They are places we had a firm opinion, someone depending on it, and the freedom to act.
Which cuts both ways
Some of this is judgement about where DuckDB workloads are heading, and judgement can be wrong. We would rather say that plainly than pretend every call is settled fact.
When one of ours turns out badly, we change it. And where a change belongs to everyone we offer it upstream — when it lands, we drop our patch and carry one less thing.
When it doesn't land, that is just as good an outcome. DuckDB answers to a far wider audience than we do, and a change that is right for the people running Haybarn does not need anyone else's agreement to be worth shipping. It stays here, and we maintain it. What you are choosing is a distribution with a point of view, and people who will keep exercising it.
Adopt the distribution without rewriting the work
Same SQL
Queries behave exactly as they do on DuckDB.
Same files
.duckdb files stay compatible with DuckDB v1.5.5.
Same extension commands
INSTALL and LOAD keep the familiar shape.
One-line Python path
import haybarn as duckdb, once the library package is live.
Extensions, ready to load
Haybarn rebuilds DuckDB extensions, signs them, and tracks whether they are ready for each release. Nothing is claimed that isn't measured.
Same names
Familiar INSTALL and LOAD commands, resolved from the Haybarn channel.
Core included
Common capabilities ship built and signed with the engine.
Community rebuilt
The community catalog is rebuilt against the Haybarn engine and re-signed.
The extension distribution is built for approval and repeatability: verifiable binaries, immutable hosted artifacts, published release status, and package paths that fit npm / PyPI-style dependency workflows.
Try it, or talk it through
Haybarn is MIT-licensed and free to use — start with one command above. If you're weighing it for a team, we'll walk through pinning, signing, internal mirrors, and the upgrade path — and tell you honestly if you don't need it yet.
Haybarn is not affiliated with, sponsored by, or endorsed by the DuckDB Foundation or DuckDB Labs. DuckDB is a trademark of the DuckDB Foundation. Haybarn is published by Query Farm LLC and distributed under the MIT License.