Quary - Open-Source BI for Engineers Using SQL

TL;DR

TL;DR: Quary is an open-source BI platform that lets engineers connect directly to a database, write SQL transformations and charts, and manage everything as version-controlled code — no BI工程师需要學新語言。

Source and Accuracy Notes

⚠️ This section is MANDATORY. All links must be verified from actual source, not guessed.

• Project page: quary.dev
• Source repository: github.com/quarylabs/quary
• License: Apache-2.0 (verified via GitHub API license.spdx_id)
• HN launch thread: news.ycombinator.com/item?id=40367090
• Latest release: v0.10.1 (verified 2026-06-20)

What Is Quary?

Quary describes itself as “Business Intelligence for Engineers.” Instead of a drag-and-drop query builder or a separate analytical SQL dialect, it leans on raw SQL you already know and a Rust-based CLI that manages the full lifecycle.

The core loop: connect to a database, write SQL models (essentially curated CREATE VIEW statements), add charts, and deploy the whole thing back to the database as versioned code. Dashboards are still in progress.

Supported databases include PostgreSQL, SQLite, DuckDB, BigQuery, Redshift, Snowflake, and Supabase.

Setup Workflow

Step 1: Install the CLI

On macOS or Linux:

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

Or via Homebrew:

brew install quarylabs/jary/quary

The CLI is Rust-based, so it pulls a binary — no runtime dependency needed.

Step 2: Install the VSCode Extension

The VSCode extension depends on the CLI. Install it from the marketplace, then open a project folder initialized with Quary.

Step 3: Initialize a Project

qary init

This scaffolds a quary/ directory in your project with a quary.toml config and asset type folders.

Step 4: Connect a Database

Add a connection in quary.toml:

[database]
type = "postgresql"
connection = "postgresql://user:password@localhost:5432/mydb"

Quary reads your existing database schema directly — no import step.

Step 5: Write Your First Model

Create a SQL model at quary/models/daily_revenue.sql:

SELECT
    date_trunc('day', created_at) AS day,
    sum(amount) AS revenue
FROM orders
GROUP BY 1

Step 6: Generate a Chart

Add a chart definition at quary/charts/revenue_chart.yaml:

type: line
model: daily_revenue
x: day
y: revenue
title: "Daily Revenue"

Deeper Analysis

What makes it different from dbt?

Quary is often compared to dbt, and the overlap is real — both use SQL as the primary language for transformation logic. The key differences:

• No separate staging schema. Quary deploys models directly into your existing schema (or a designated target schema you configure). dbt uses a dev/prod staging pattern.
• VSCode-first UX. dbt Core is primarily command-line; Quary pairs a CLI with a dedicated VSCode extension that surfaces schema, models, and charts in a sidebar.
• Charts and dashboards are first-class. dbt recently added semantic layer concepts; Quary bakes charting into the asset model from the start.
• DuckDB and SQLite support. Quary ships with DuckDB and SQLite drivers out of the box, making local development with sample data straightforward. dbt supports these via adapters but they are not first-party.

Version control workflow

Every asset (source, model, chart) is a plain SQL or YAML file on disk. That means:

git add quary/
git commit -m "add monthly MRR model"
git push

Rollback is standard git. Teams can review model changes in a PR just like application code.

Practical Evaluation Checklist

• Connects to an existing database without data duplication
• SQL models compile and deploy to the target schema
• VSCode extension renders schema browser and model lineage
• Charts render from SQL model output
• CLI qary init, qary build, qary test run without errors
• Git-based version control works on all asset types

Security Notes

• Credentials are stored in quary.toml — never commit this file to version control. Add it to .gitignore.
• Use environment variable substitution or a secrets manager for connection strings in production.
• Quary reads your database; it does not modify your raw source tables without explicit model definitions.

FAQ

Q: Does Quary require a separate analytical database or can it use my existing production DB?

A: It can use your existing production database. You point it at any supported database (PostgreSQL, BigQuery, Snowflake, etc.) and it reads the schema directly. Models deploy to a target schema you specify — Quary does not touch source tables.

Q: Is there a managed cloud version?

A: Not yet. Quary is fully self-hosted. You run it on your own infrastructure.

Q: How is it licensed?

A: Apache-2.0, confirmed via the GitHub API license field.

Q: Can I use Quary without VSCode?

A: Yes. The CLI (qary) covers initialization, building, testing, and deployment. The VSCode extension adds a GUI layer but is not required.

Conclusion

Quary is a practical option for engineering teams that want BI tooling grounded in SQL and git, without learning a new DSL or committing to a proprietary analytical engine. It is still young — dashboards and reports are marked WIP — but the core loop (schema → SQL model → chart → deploy) works today.

If your team already lives in VSCode and prefers to keep analytical logic in version-controlled SQL files, Quary is worth evaluating. The DuckDB/SQLite local mode is particularly useful for spinning up a personal analytical environment without cloud credentials.

For teams already invested in dbt, the migration cost is non-trivial and the feature set gaps (especially around data testing and the semantic layer) may not justify switching.