# Quary: SQL-First Business Intelligence for Engineers

> Quary is an Apache-2.0 BI tool that lets engineers define sources, models, charts and tests as SQL files in a repository. It installs as a Rust CLI plus a VSCode extension and supports DuckDB, PostgreSQL, Snowflake, BigQuery, Redshift, Supabase and SQLite.

**quarylabs/quary** — Open-source BI for engineers

- Repository: https://github.com/quarylabs/quary
- Website: https://www.quary.dev
- Stars: 2,385 · Forks: 57
- Language: Rust
- License: Apache-2.0
- Published: 2026-09-28 · Updated: 2026-09-28 · Language: en
- Canonical page: https://hysenlabs.com/projects/quarylabs-quary

## The Problem Quary Targets: BI Logic That Lives Outside Version Control

Most BI tools put the definition of a metric inside a proprietary semantic layer that only the tool can read. Quary takes the opposite position. The README states that engineers can "write SQL queries to transform, organize, and document tables in a database" and then "deploy the organised, documented model back up to the database." The unit of work is a SQL file in a repository, not a drag-and-drop canvas.

The audience is explicit in the tagline: business intelligence for engineers. That means people who are comfortable with Git, who want to review a change to a revenue definition the same way they review a change to application code, and who would rather write a test assertion in SQL than click through a configuration wizard. If your organization's analysts work entirely in a browser and have no repository access, Quary's workflow assumes a skill set they may not have.

The repository layout supports this reading. There is a rust/ directory with a cli and a core crate, a proto/ directory holding service definitions, and a js/ directory containing the VSCode extension packages. The CLI is the engine; the extension is the interface.

## How Quary Organizes Work: Sources, Models, Charts and Tests as Assets

Quary defines four asset types as code. Sources describe external data, which the README says can be database tables, flat files, or APIs when DuckDB is the target. Models are SQL transformations that turn sources into analysis-ready datasets; the README frames them as a way to "split complex queries into atomic components," which is the same decomposition argument dbt makes. Charts are visual representations defined using SQL. Dashboards and reports are listed with a construction marker and described as work in progress.

The build sequence is the part that distinguishes Quary from a pure transformation tool. The README's sample workflow runs four commands in order. quary compile validates project structure and model references without touching a database, so a broken reference fails before any query is sent. quary build then executes the model views or seeds against the target database. quary test -s runs defined tests against that database. The separation between compile and build is meaningful: it means reference errors and structural problems surface in a fast, offline step, while the slower database round trip is reserved for the step that actually needs it.

Under the hood, the Cargo workspace lists a rust/core crate, a rust/cli crate, a rust/dbt-converter crate, a rust/wasm-binding crate, and a proto/gen/rust member. The dbt-converter crate is notable because it implies a migration path from dbt projects, though the README does not document how that conversion works or what it preserves. The wasm-binding crate and the Makefile target rust_build_wasm, which builds for wasm32-unknown-unknown and runs wasm-bindgen into the extension's source directory, explain how the same core logic runs inside the VSCode extension without a separate implementation. The SQL parsing dependencies are sqruff-sqlinference, sqruff-lib-core and sqruff-lib-dialects at version 0.34.1, which ties Quary's dialect handling to the same team's SQL linter project, SQRUFF.

## Installing Quary and Running a First DuckDB Project

Quary ships as two pieces. The VSCode extension is the interface and is installed from the Visual Studio Marketplace under the identifier Quary.quary-extension. The README notes that the extension depends on the CLI being installed, so install the CLI first.

On macOS or Linux with Homebrew, the CLI comes from the project's own tap:

```bash
brew install quarylabs/quary/quary
```

If Homebrew is not available, the README gives a curl installer for Linux and macOS:

```bash
curl -fsSL https://raw.githubusercontent.com/quarylabs/quary/main/install.sh | bash
```

Prebuilt binaries for other platforms are listed on the releases page. Note the release cadence visible in the repository: v0.10.1 was tagged on 2026-01-23, following v0.10.0 on 2026-01-07 and v0.9.0 on 2025-08-01. The workspace Cargo.toml carries version 0.10.1, so the crate version tracks the release tag.

Once the binary is on your PATH, the README's getting-started sequence creates a demo project backed by DuckDB with sample data:

```bash
mkdir example
cd example
quary init
quary compile
quary build
quary test -s
```

quary init scaffolds a DuckDB demo project. quary compile checks the project structure and model references without connecting to a database, so a successful run here means the file layout and references are internally consistent. quary build executes the model views and seeds against the target database, which in the demo case is DuckDB. quary test -s runs the tests defined in the project against that database. The -s flag is the only flag the README shows for the test command; other options are not documented in the README and would need to come from the CLI's own help output.

After the demo runs, the extension can be pointed at the same folder. The README does not describe the extension's connection setup steps, so that part of the workflow is documented only on the project's documentation site.

## Where Quary Is Not the Right Tool Yet

The clearest limitation is stated by the project itself. Dashboards and reports are marked as work in progress in the README's asset list, and the feature list describes chart, dashboard and report creation with the parenthetical "in development." An organization shopping for a finished dashboarding product will find that half of the promised surface does not exist yet. Models, sources, charts and tests are the parts the README presents as usable.

Database support is a second boundary. The README lists seven targets: Amazon Redshift, Google BigQuery, PostgreSQL, Snowflake, Supabase, DuckDB and SQLite. Supabase appears alongside PostgreSQL, which suggests it is handled through the Postgres wire protocol, but the README does not explain whether Supabase support differs from plain PostgreSQL in any way. Warehouses outside that list, such as ClickHouse, Databricks SQL or Microsoft Fabric, are not mentioned anywhere in the README, and there is no documented plugin interface for adding a dialect.

A third constraint is the toolchain. The Cargo.toml sets rust-version to 1.86.0 and edition 2021, and the root package.json requires Node.js at ">=22.0.0 <23.0.0" and pnpm at ">=10.0.0". Those Node and pnpm bounds apply to building the extension from source, not to using the released CLI, but they matter if you intend to build the extension yourself or contribute. The version ceiling on Node, in particular, means a machine running Node 24 cannot build the extension without changing the engines field.

Finally, the README does not document rollback behavior. If quary build deploys a model to a warehouse and the result is wrong, the README gives no command for reverting the previous state. The project's version-control framing suggests the intended answer is to revert the SQL in Git and rebuild, but that is an inference from the workflow, not something the documentation states.

## Quary and dbt: Two Answers to the Same Question

The obvious comparison is dbt, and the repository itself acknowledges it by including a rust/dbt-converter crate. Both projects treat SQL transformations as versioned files and both produce a dependency graph of models. The difference is where the boundary sits.

dbt is a transformation framework. Its job ends when the models are materialized in the warehouse; visualization happens in whatever BI tool reads the resulting tables. Quary's README claims a wider scope, covering sources, models, charts, dashboards and reports, with the intent that the same repository produces both the data and the view of it. That is a real architectural difference: in the dbt model, the semantic definition of a metric and its presentation are separate artifacts that can drift; in Quary's model, they are supposed to be the same file tree.

That wider scope is also why Quary's dashboard layer is incomplete while dbt's transformation layer is not. Quary is attempting more, and the README admits as much by marking the presentation assets as unfinished. A team that needs a working transformation tool today and has no interest in charts would get nothing from Quary that dbt does not already provide, and would take on a younger codebase. A team that wants the model and the chart to live in one repository, and can accept that dashboards are still being built, is the case Quary is designed for.

The test command is a smaller but concrete difference. dbt's test command requires a selection flag to run only one category; Quary's README shows quary test -s as the documented invocation, with the -s flag's meaning left unexplained in the README text.

## Licence, Maintenance and the Cost of Upgrading

Quary is licensed under Apache-2.0. The workspace Cargo.toml sets license to "Apache-2.0" for the Rust members, and the repository root contains a LICENSE file. Apache-2.0 permits commercial use, modification and redistribution, and includes an explicit patent grant. It does not require derivative works to be open sourced. This is a permissive licence, which matters for teams that want to embed the CLI in an internal platform without publishing their changes. It is not legal advice; the terms that apply to your use are in the LICENSE file.

The last push to the default branch was on 2026-09-14, and the repository is not archived. The most recent tagged release is v0.10.1 from 2026-01-23, so the gap between the latest tag and the latest commit is roughly eight months. Commits continue; tagged releases do not appear at the same pace. Anyone pinning to a release should check whether the behavior they need landed after v0.10.1 and is only available from main.

Upgrade cost has two parts. The CLI is a single binary, so replacing it is a download or a brew upgrade. The extension is versioned separately through the Makefile target bump_version_patch, which runs npm version patch against js/packages/quary-extension. That means the CLI version and the extension version are not the same number, and a mismatch between them is possible. The README states the extension depends on the CLI but does not specify a compatibility range, so the safe assumption is that the two should be updated together.

Building from source adds the Bazel and pnpm layers visible in the repository root. The Makefile's proto target regenerates protobuf code for both Rust and TypeScript, runs buf lint and buf generate, and copies generated TypeScript into js/packages/proto/src/generated/. The rust_lint target runs cargo fmt --check and cargo clippy. A contributor needs Rust 1.86.0 or newer, Node 22, pnpm 10, buf and Bazel, which is a heavier setup than the released binary requires.

## Conclusion

Quary fits engineering teams that already keep SQL in Git and want models, tests and charts to live in the same repository as the transformation logic. Teams that need mature dashboards today should not adopt it yet, because the README marks dashboards and reports as work in progress. Verify first that your warehouse is one of the seven listed dialects, that the CLI installs on your platform, and that the project structure produced by quary init matches how you intend to organize sources and models.

## FAQ

### What databases does Quary support?

The README lists Amazon Redshift, Google BigQuery, PostgreSQL, Snowflake, Supabase, DuckDB and SQLite. DuckDB is the target used by the demo project created with quary init. Warehouses outside that list are not mentioned.

### How do I install Quary?

The CLI installs with brew install quarylabs/quary/quary on macOS or Linux, or through the curl installer the README gives for Linux and macOS. The VSCode extension installs separately from the marketplace as Quary.quary-extension and depends on the CLI being present.

### What is the difference between quary compile and quary build?

quary compile validates the project structure and model references without connecting to a database. quary build then builds and executes the model views or seeds against the target database. Splitting the two means reference errors surface before any query runs.

## Sources

- [License: Apache-2.0](https://github.com/quarylabs/quary/blob/main/LICENSE)
- [Project website](https://www.quary.dev)
- [quarylabs/quary on GitHub](https://github.com/quarylabs/quary)
- [README](https://github.com/quarylabs/quary/blob/main/README.md)
- [Releases](https://github.com/quarylabs/quary/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/quarylabs-quary