Short pieces on how the SQL Browser works and why it's built this way — one idea each.
One HTML file ClickHouse serves itself, OAuth in the browser, per-user grants, zero third-party requests, and a CSP that enforces it.
Drag a database onto the results pane and get a typed data-flow graph — materialized views, dictionaries, Distributed tables — discovered structured-first, parse-fallback.
EXPLAIN PIPELINE as a processor DAG you can pan and zoom — read parallelism and the Resize funnel at a glance, the way you read a flame graph.
Paste a ;-separated script and it runs each statement in order, like clickhouse-client --multiquery — with run-selection, sessions for temp tables, and a per-statement result grid.
Stream a query's result to a file (or a script's results to a folder of files) via the File System Access API — uncapped, any ClickHouse format, flat memory, and a mid-stream error is never baked into the file.
Build queries with titles and descriptions, save the library as one file, commit it — then export to a Markdown runbook or a runnable .sql that clickhouse-client, DBeaver and DataGrip can execute.
A zero-dependency Python runner serves the app locally against any cluster in your clickhouse-client config. Needs only python3; queries go straight to the cluster.