Workflow

A query library you can commit, share, and run anywhere

Altinity engineering·June 2026·5 min read

The useful queries always end up somewhere useless — a Slack DM, a stale wiki, someone's ~/scratch.sql. Yours should be a file you can commit.

Every team that runs ClickHouse accumulates a folklore of queries: the one that finds parts about to hit the merge limit, the revenue rollup with the three joins nobody wants to rewrite, the lag check you paste during an incident. They live in chat history and people's heads. New hires re-derive them. I've done it; you've done it.

So the SQL Browser treats saved queries as an artifact, not app state. Save a query with ⌘S, give it a name and a description, star the ones you reach for, search the rest. The whole collection is a named library — and that library is one file.

The Save Query dialog with a name field and a description field.
Every query gets a name and a description. The description isn't decoration — it travels with the query into every export.

It's a file, so treat it like one

File ▾ → Save writes the library as JSON. Open loads someone else's. Append merges one into yours and de-dupes, so two people can maintain overlapping sets without clobbering each other. That's the whole sharing story — no accounts, no server, no "export to cloud." Sharing a library is sending a file.

Which means it belongs in git. Check queries.json into the repo next to the schema it queries. Review changes to it in a pull request like any other code. Onboard someone by pointing them at the file instead of a search through Slack. The library stops being one person's browser state and becomes something the team owns and versions.

The File menu: New Library, Save JSON, Open, Append, Download Markdown, Download SQL.
JSON round-trips everything; Markdown and SQL are one-way exports for humans and other tools.

Two exports, two audiences

The JSON is lossless — it round-trips the SQL, the name, the description, even the chart config and the view you left each query on. But not everyone who needs these queries opens the browser, so the library exports two other ways.

Download Markdown gives you a document. Each query becomes a heading, its description, and a fenced SQL block — a cookbook you can paste into a README, a wiki, or a Notion page and it renders everywhere:

### Revenue by category

Revenue per product category from category_revenue — the
mv_category_revenue view derives the category with dictGet().

```sql
SELECT category, sum(revenue) AS revenue
FROM shop.category_revenue
GROUP BY category
ORDER BY revenue DESC
```

Download SQL gives you a program. Each query is a comment carrying its name and description, then the statement, semicolon-terminated:

/* Revenue by category
Revenue per product category from category_revenue — the
mv_category_revenue view derives the category with dictGet(). */
SELECT category, sum(revenue) AS revenue
FROM shop.category_revenue
GROUP BY category
ORDER BY revenue DESC;

The .sql is just SQL — run it anywhere

That second file is the one I keep coming back to. It's a plain SQL script, so it runs without the browser anywhere in your stack. Pipe the whole library through the CLI:

clickhouse-client --queries-file team-queries.sql
# or
clickhouse-client < team-queries.sql

Or open it in DBeaver or DataGrip and step through it statement by statement — the /* … */ comment above each one tells whoever's driving what it does and why. The same file is a scheduled job's input, a migration reviewer's reference, and a teammate's starting point in whatever client they already use. Author the queries once, with charts and context, in the browser; hand off a format that outlives it.

We dogfood this: the chart demos on the site are a library file — examples/shop-charts.json, eight queries with descriptions and chart configs. Download it, File ▾ → Open on the demo, and you're editing the same library these examples ship as. Then export it to .sql and run it from your own client.

More from the blog:
A ClickHouse console in one curl → Map the materialized-view web → The SQL console with no backend →