Compatibility & FAQ
Haybarn is ABI- and file-format-compatible with upstream DuckDB. In most cases, migrating is a package-name swap.
duckdb:: namespaceduckdb.h / .hpp)DUCKDB_VERSION macro.duckdb_extension suffixlibhaybarn.*)~/.haybarn/extensions/)jdbc:haybarn:)Migration
# Drop-in:
import haybarn as duckdb
duckdb.sql("SELECT 42").show()
# Or, for third-party code that hard-imports duckdb:
import haybarn.compat # registers haybarn as the duckdb module
import duckdb # now resolves to Haybarn- import { DuckDBInstance } from '@duckdb/node-api';
+ import { DuckDBInstance } from '@haybarn/node-api';- import org.duckdb.DuckDBDriver;
+ import farm.query.haybarn.HaybarnDriver;
- jdbc:duckdb::memory:
+ jdbc:haybarn::memory:The Haybarn CLI ships today via npm and PyPI. The Python library, Node, and JDBC bindings are still rolling out — track readiness on the status page.
FAQ
No — it's a derived distribution, the same relationship Ubuntu has to Debian. The engine source tracks upstream DuckDB and Haybarn ships on DuckDB's release cadence. What Haybarn adds around the engine (coordination with the extension catalog at release time, signing pipeline, package formats, extension distribution channels) is independent and tuned for the audience running it in production. Another precedent for the same shape: OpenSSH-portable to OpenBSD's OpenSSH.
A few production-oriented additions on top of the same engine. (1) A curated extension catalog: the open-source set DuckDB CI builds, with third-party vendor extensions left out of the default install path. (2) Extensions ready alongside the release — common community extensions built and available when we ship (more in the release-coordination question below). (3) Mirrored extension distribution across R2, PyPI, and npm, so teams can pick the path that fits their supply chain. (4) Extension version pinning, coming with the PyPI / npm rollout so extensions can live in lockfiles. (5) Strict API and file-format stability across RCs, so an upgrade is never a surprise.
Same engine source, same SQL, same on-disk format, same C/C++ API, same release cadence (Haybarn ships when upstream ships). What differs is artifact names, package formats (CLI via npm/PyPI/GitHub Releases; extensions also via PyPI/npm — planned), extension trust root, extension cache directory (~/.haybarn/extensions/), the supply-chain signing pipeline (SLSA provenance, GPG-signed releases, immutable R2 hosting), and a focus on having common community extensions built and ready when we ship.
MIT — the same license as DuckDB. The upstream license is preserved verbatim in the LICENSE file. The NOTICE file documents Haybarn's modifications.
Once the extension catalog has stabilised — track readiness on the Haybarn status page. APIs and on-disk formats are inherited from upstream DuckDB v1.5.3 and will not change between release candidates.
Yes. On-disk database format is unchanged. A database file written by DuckDB v1.5.3 opens cleanly in Haybarn v1.5.3, and vice versa.
No — because the signing key is different. Haybarn rebuilds the DuckDB community extension catalog against the Haybarn engine and re-signs every binary with the Haybarn key. That coverage is what makes the disjointness practical: the extensions you want still load, just from the Haybarn channel.
Not today. Both use the same model — RSA-signed binaries verified against a trust root baked into the engine. The Haybarn key is a different key, not a stronger one. The benefit is option value: Haybarn can evolve the model on its own timeline (revocation, multi-signer, customer trust roots, hash-pinned allowlists) when users need it.
Those are good projects from companies with their own commercial interests. Haybarn's default catalog is the set DuckDB's own CI builds minus third-party vendor extensions, so a Haybarn session won't autoload or autoinstall vendor code without you opting in. Nothing prevents you from configuring those extensions yourself — they're just not in the default install path, and motherduck is explicitly removed from the engine's autoloadable list with that rationale documented in source.
Narrow and explicit. Autoload — the engine automatically loading an extension when a query references it — is a convenience that can become a surprise: a query you wrote ends up pulling in third-party vendor code you didn't intend to depend on. Haybarn's default autoloadable list excludes third-party vendor extensions. The full autoloadable list lives in extension_entries.hpp.
Via npm today. Haybarn publishes community extensions as npm packages, so you can pin an exact version in package.json, mirror it to an internal registry, and let your lockfile record it. PyPI wheels — pinnable the same way in requirements.txt — are rolling out for the GA window. The engine's own INSTALL command doesn't carry pinning syntax yet; it resolves to whatever's currently on R2, same as upstream DuckDB. Engine-side pinning (immutable artifacts keyed by extension commit sha) is on the roadmap. The INSTALL / LOAD network channel keeps working in parallel — lockfile pinning is additive, not a migration.
Haybarn ships on DuckDB's release cadence — same version numbers, same upstream timing. What we add is care around extension readiness: when we cut a release, we work to make sure common and popular community extensions are built and available alongside it. When an extension that built before starts failing on a new release, we reach out to the maintainer directly to help land a fix — we want them to ship right alongside us. The status page shows the current matrix in flight.
Haybarn is publishing every extension through three channels — R2 (the default the engine reaches at INSTALL time), PyPI, and npm. Teams can pick the path that fits their supply chain — registry pin for reproducibility, R2 for the standard INSTALL flow, internal mirror for air-gapped environments. PyPI and npm packages are pinnable in lockfiles, so once installed they don't need to reach the network at runtime.
If it lands in duckdb/community-extensions upstream, Haybarn rebuilds it automatically. The Haybarn community-extensions repo is a CI mirror of the upstream catalog — when upstream merges a new extension or updates an existing one, the next Haybarn build picks it up, rebuilds against the Haybarn engine, signs with the Haybarn key, and publishes. See the community-extensions page for the full pipeline.
No. Haybarn is published by Query Farm LLC and is not affiliated with, sponsored by, or endorsed by the DuckDB Foundation or DuckDB Labs. DuckDB is a trademark of the DuckDB Foundation.
Informally. The Query.Farm team behind Haybarn has been part of the DuckDB community for years — we've shipped 30+ community extensions and landed changes in DuckDB core. We follow DuckDB's trademark guidelines and we work hard to make Haybarn a good citizen in the ecosystem. We haven't asked DuckDB Labs for any formal blessing because they're busy building the engine and we're focused on the distribution layer around it — both roles matter, and they're separate by design. Where our work benefits upstream we contribute it back; where DuckDB Labs ships improvements we pull them in.
A simple rule that helps everyone: if you can reproduce the bug on upstream DuckDB, please file it with the DuckDB project — that's where engine-level bugs get the best attention and the fix benefits the whole ecosystem. If the bug only reproduces on Haybarn (one of our build-fork patches, the signing pipeline, the community-extensions catalog, our duckdb-wasm build), open an issue on the relevant Query-farm-haybarn repo and we'll take it from there. Query.Farm also offers commercial support if you'd prefer a single point of contact for both sides.
Expert help
We help teams evaluate Haybarn against their compliance and supply-chain needs, and roll it out alongside (or instead of) upstream DuckDB.