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:)# 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.
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 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 you can pick the path that fits your supply chain. (4) Extension version pinning the engine actually remembers, and extensions loadable straight from node_modules. (5) A small set of engine changes — HTTP/2 multiplexing and standards-compliant conditional reads for object-store scans, and a pg_catalog strict PostgreSQL drivers can read. (6) 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), a focus on having common community extensions built and ready when we ship, and a small curated set of engine changes. The full inventory of those changes — version pinning, node_modules extension loading, pg_catalog fixes, HTTP/2 multiplexing, conditional reads — is on the what's different page.
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.5 and will not change between release candidates.
Yes. On-disk database format is unchanged. A database file written by DuckDB v1.5.5 opens cleanly in Haybarn v1.5.5, 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.
Two ways, and they compose. Via npm: 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 — and Haybarn will then load that extension straight out of node_modules with no INSTALL and no network at query time. PyPI wheels, pinnable the same way in requirements.txt, are rolling out for the GA window. Via the engine: INSTALL <ext> VERSION '<sha>' records the pin and honours it on later installs, and duckdb_extensions() exposes it as pinned_version. Upstream DuckDB accepts the same syntax but discards the version after building the download URL, so the pin is obeyed exactly once. See the what's different page.
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.
We help teams evaluate Haybarn against their compliance and supply-chain needs, and roll it out alongside (or instead of) upstream DuckDB.