Connect the data and code you already run to people, applications, and agents—without
rebuilding the integration for every consumer. Query.Farm does this in DuckDB today
through open extensions and VGI, with a path to more engines over time.
Connect every place a question starts to the capability that answers it.
Query.Farm connects the tools people use to query engines, extensions, authorization,
distributed workers, and the data or compute behind them. Explore the six layers to see
what works today, what can be added when needed, and where the platform is heading.
Working todayExtensions, VGI for DuckDB, Haybarn, and Cupola
Optional when neededRowfence authorization and policy
Coming nextManaged Orchard workers and more engine integrations
01 / 06
Query surface
Questions start wherever people work.
Available entry points
Query.Farm does not require everyone to adopt one interface. Analysts can work directly in Cupola; applications and BI tools can connect through DuckDB’s existing drivers; engineers can use notebooks and the CLI; and agents can reach governed data tools through MCP.
Cupola runs a complete SQL workbench in the browser—with pivots, charts, and a built-in AI analyst.
ADBC and ODBC connect applications and BI tools through standard database interfaces.
MCP, Jupyter, Python, dbt, and the CLI support agents, exploration, and automated workflows.
Why it matters
One integration, without forcing one user experience.
For leadership
Give each team an interface that fits its work without funding a separate integration for each one.
For builders
Keep using familiar DuckDB clients and tools; the capability appears as SQL rather than a new application API.
02 / 06
SQL engines
The capability should outlive the engine choice.
DuckDB today · an open path forward
DuckDB is the engine where Query.Farm’s integration model works today. Haybarn packages that foundation as an independently released distribution with signed binaries, rebuilt extensions, supply-chain review, and compatibility with ordinary DuckDB SQL and database files.
Use upstream DuckDB directly, or choose Haybarn for Query.Farm-controlled releases and extension channels.
Haybarn remains ABI- and file-format-compatible with DuckDB and uses familiar INSTALL and LOAD commands.
VGI separates capabilities from engine internals, creating a path to other query engines without claiming those integrations exist today.
Why it matters
Adopt what works now without making today’s engine tomorrow’s boundary.
For leadership
Start with a proven embedded engine while preserving leverage over distribution, release cadence, and future architecture.
For builders
Choose the DuckDB distribution that fits deployment and supply-chain requirements without rewriting SQL or moving database files.
03 / 06
Engine integration
Put each capability on the right side of the process boundary.
Extensions and VGI available today
Query.Farm offers two complementary ways to add capability. Native DuckDB extensions put installable SQL functions and connectors inside the engine. The Vector Gateway Interface exposes ordinary programs as SQL-visible catalogs and functions across a process or network boundary.
Choose from 32 published extensions for connectors, transformations, sketches, scripting, and specialized SQL functions.
Build VGI workers in Python, TypeScript, Go, Rust, or Java without FFI, engine rebuilds, or version locking.
Move typed data through Apache Arrow IPC over pipes, Unix sockets, TCP, or HTTP.
Why it matters
Use in-process speed where it matters and service boundaries where they help.
For leadership
Turn one-off connector work into a reusable capability with an explicit deployment and ownership boundary.
For builders
Use a native extension for engine-local work; use VGI when the best library, runtime, hardware, or security boundary lives elsewhere.
04 / 06
Access control
Add policy when the data demands it.
Optional governance layer
Rowfence is a policy-driven authorization service that can sit between a query engine and any VGI worker. It decides on every query which rows, columns, schemas, and functions a caller may use—without making each worker implement its own policy engine.
Carry caller identity through the VGI request and evaluate authorization before the worker returns data.
Apply policy below the table level, including row filters, column visibility, schemas, and functions.
Deploy the policy service only where shared or sensitive capabilities require it; direct worker connections remain valid.
Why it matters
Keep experimentation light and make the same path credible for enterprise access.
For leadership
Create a credible path from a useful prototype to a shared service without waiting to solve every governance problem on day one.
For builders
Keep policy, identity, and audit decisions outside application workers so capability code stays focused on the underlying system.
05 / 06
VGI execution
Run the code where the code belongs.
Self-run today · managed Orchard coming soon
A VGI worker is a normal program that turns existing code into SQL-visible tables and functions. It can run as a child process beside DuckDB, near a private service inside your network, on a GPU host, or behind ordinary HTTP. The Orchard platform will make workers discoverable and available as managed services.
Package proprietary libraries, internal APIs, models, or operational logic in the language that already supports them best.
Choose local process, socket, network, or HTTP deployment without changing the SQL-facing contract.
Use Orchard’s worker catalog to discover reusable integrations; managed VGI workers are coming soon.
Why it matters
Reuse working application code instead of rebuilding it as database infrastructure.
For leadership
Keep ownership with the team that understands the source while making the resulting capability reusable across the organization.
For builders
Deploy a worker next to the system, library, or hardware it needs instead of forcing that dependency into the query engine process.
06 / 06
Data & compute
Anything a worker can reach becomes part of the query.
Your systems, exposed through one query model
The destination can be an API, service, database, file, model, live stream, or application library. The worker owns the system-specific authentication and behavior; the engine sees typed Arrow data, SQL tables, and functions. The difficult integration is built once and reused from every supported query surface.
Put SQL in front of legacy systems and proprietary formats that cannot be rewritten.
Expose APIs, event streams, models, and compute as catalogs, table functions, or scalar functions.
Join remote capabilities with Parquet, CSV, Iceberg, Delta Lake, databases, and in-memory data in the same query.
Why it matters
Build the difficult integration once, then make it useful in more places.
For leadership
Replace repeated point-to-point integrations with a capability that can serve analysts, products, customers, and agents.
For builders
Keep source-specific complexity inside one worker and give every consumer a typed, composable SQL contract.
Query.Farm product mapQuery surface
↕ Scroll to explore each layer
What it means for you
One architecture, three ways to evaluate it
For CEOs01
Turn integration work into a reusable asset.
Start with one valuable source or workflow, prove it in a real query, and create a path to reuse it across teams and products. Query.Farm’s open foundations keep the first step useful even before a broader platform decision.
Business outcome: less repeated connector work and a clearer path from prototype to product.
Use Apache Arrow IPC, ordinary processes, familiar transports, and a protocol that can span engine boundaries. Deploy locally, over HTTP, or inside your own network; add policy and managed operation only where the organization needs them.
Architecture outcome: a smaller integration surface with explicit security and deployment boundaries.
Wrap an API, library, model, or internal service in a VGI worker, or choose a native extension for in-process work. Query it from DuckDB today, join it with files and databases, and use the language and tooling that fit the source.
Engineering outcome: less glue code between each source and each consumer.
This is not a promise that begins after a platform is finished. Each layer has to be
useful on its own, then become more valuable as the neighboring layers arrive.
01
Built foundations
Useful before it is a platform
DuckDB extensions, VGI, Haybarn, and Cupola already solve concrete problems: add SQL capabilities, reach external code, ship a controlled engine, and explore data in the browser.
Rowfence adds optional row-, column-, schema-, and function-level policy. Orchard is the coming managed home for VGI workers. Together they turn a useful worker into an operable, governable organizational capability.
DuckDB is the proving ground, not the limit. The long-term direction is for VGI-backed capabilities to meet teams in the engine they choose—DataFusion, Trino, Spark, SQLite, Polars, and what comes next.
Bring us the data, API, or code your team cannot query cleanly.
In thirty minutes, we can place it on the map: what should run in-process, what belongs
in a worker, where policy matters, and whether Query.Farm already has the piece you need.
No deck, and no platform prerequisite.