For data engineers: VS Code, CLI, browser, Docker
Keep your data model next to your code: tables, relationships, owners and policies as plain files in Git. Edit them on a canvas in VS Code or your browser, script them from the CLI, and import from dbt, SQL scripts and more.
Get started Live demo (opens in a new tab) View on GitHub
Strata SQL keeps the diagram, the rules about the data and the change history in one place next to your code.
Point Strata SQL at the .sql files you already have, or at a dbt project (run dbt parse first, no warehouse needed). Or begin from a blank model, Northwind, FpML or a small dimensional star. You see a preview before anything is written.
# in VS Code: Command Palette
Strata SQL: Import from DDL…
Strata SQL: Import from dbt…
Strata SQL: New Project
# or from a terminal
strata-sql import-sql --ddl schema.sql
strata-sql import-dbt --from ./analytics --name "Jaffle Shop"Add tables, relationships and metrics; move between six views of the same model. Attach tags, policies, owners and classification: they flow down the hierarchy, and warnings flag the gaps.
The model, its version log and its layout sit in your repository. The log merges in Git without conflicts. Assistants read a compact summary instead of the whole file.
my-project/
strata.project.json
data_models/northwind/
northwind.model.json # the model
northwind.model.layout.json # card positions
history/northwind.history.jsonl # every change, hash-chainedStrata SQL reads what you already have and writes plain files, so it sits next to your code, your pipelines and your tools.
Reads manifest.json (run dbt parse, no warehouse). Re-sync any time; what you added is kept.
CREATE TABLE files, pg_dump, GET_DDL and your queries, in eleven dialects. It reads SQL and never runs it.
The model, its version log and its layout are plain files. The log merges in Git without conflicts.
Starter DAGs, assets or a notebook, generated from the load order of your tables.
strata-sql creates, imports, splits and joins projects, and opens the editor in your browser.
Compact summaries and one-table answers instead of the whole file: 118× fewer tokens for one answer, measured.
Ten database technologies set the data types, naming and DDL. Product names belong to their owners; Strata SQL is an independent project and is not affiliated with any of them.
Every clip is recorded from the real product on the sample models, not mocked up. Click a clip to see it larger.
Levels
Sketch business concepts, refine them into entities with keys, and land on the physical tables and the metrics on top. The levels are linked: descriptions and tags flow down, and an alignment check warns when something no longer lines up.
Governance
Attach policies such as GDPR to tags or to objects. Owners, stewards and criticality are set per level and inherited. Classification works the other way: a table shows the highest classification of the columns it holds. Warnings flag gaps, like personal data with no masking policy.
Impact
Pick a column, table or schema and everything that depends on it turns red: foreign keys, views and metrics. It also lists columns nothing uses. It sees what is in the model, so applications outside the model are still yours to check.
History
Edits are written to an append-only log next to the model, checked with a hash chain. Undo, redo and preview any point in time; an edit after an undo never deletes what was undone. Two branches that both changed the log merge in Git, and Strata SQL shows what each side changed.
Integration: dbt
Run dbt parse (no warehouse needed), point Strata SQL at the project, and get tables, columns, keys, relationships, lineage and metrics. You see a preview first. Re-sync later: what dbt owns is updated, what you added is never deleted or overwritten.
Strata SQL reads dbt's manifest.json and your model SQL. It is a reader, not dbt: some macro-generated SQL gives fewer columns, and Strata SQL lists what it could not read.
Integration: SQL scripts
Point Strata SQL at a pg_dump, a mysqldump, SSMS scripts, Snowflake GET_DDL or the CREATE TABLE files in your repository. Tables, columns, keys and foreign-key relationships fill the physical level; your reports and views add starter metrics, joins and lineage. No database connection: nothing runs.
Eleven dialects are read, detected for you and confirmed by you. You see a preview first. Re-sync later: what the scripts own is updated, what you added is never deleted, and your descriptions are never overwritten.
It reads SQL, it does not run it. Stored procedures and other procedural code are listed, not read. Tested against hand-written samples in the style of each tool, not yet against real production dumps.
# schema.sql: two CREATE TABLEs, one foreign key, one COMMENT
# reports.sql: one SELECT with SUM, COUNT and GROUP BY
strata-sql import-sql --ddl schema.sql --dml reports.sql --dry-run
New project from SQL scripts in .: 2 tables added, 7 columns added,
1 relationship added, 1 tag added, 2 metrics added, 1 schema added
(dry run, nothing written)
+ schema public
+ table public.customers (3 columns)
+ table public.orders (4 columns)
+ relationship public.customers.customer_id -> public.orders.customer_id
(declared foreign key)
+ metric Revenue (derived from SQL)
+ metric Orders (derived from SQL)
+ tag sql-derived
Notes:
read: 2 files as PostgreSQL (detected, not certain: check it),
2 table and views, 1 query statement
Run it again without --dry-run to apply.Domains
Group concepts into domains such as Sales or Catalog, each with an owner. Split the project into one file per domain, so teams work in parallel, and still open the whole project on a single canvas with every card badged by its domain.
Load order
Find out which tables must load first, which can load in parallel and what waits for what, with optional data-availability SLAs. Turn it into a starter Airflow DAG, Dagster assets or a notebook.
No server, no account. Each part below is in the product today.
Concepts, entities, tables and metrics in one file, kept in line by an alignment check.
Define metrics and see which tables they read and how they are calculated.
Tags, policies, owners, stewards and classification, with warnings for gaps.
Select a column, table or schema and see what depends on it.
An append-only, hash-chained log with undo, redo and point-in-time preview.
From manifest.json and your model SQL, without a warehouse.
Tables, keys and relationships from your DDL; metrics from your queries.
One file per domain, one canvas for the whole project.
Stages, parallel loads, and starter Airflow or Dagster code.
The model, log and layout are readable files; the log merges without conflicts.
strata-sql creates, imports, splits and joins projects from a terminal or a script.
The same editor in your browser with strata-sql live, or served from a Docker image.
The saved model file is readable, not small. What keeps an assistant's context small is asking for the part you need.
.model.json15,942CREATE TABLE DDL, for comparison4,486summary: every column, one line each3,254summary --brief: names and keys1,156show orders: one table and its relationships689path orders products: how to join two tables179gov customers: owner, class, policies135Measured on one machine with a Gemma tokenizer (other tokenizers differ, roughly plus or minus 20 %). Bars share one linear scale. The file is 3.6 times the DDL because it also holds levels, governance, metrics and named relationships. On the larger FpML sample (67 tables) the file is 44,684 tokens and summary --brief is 3,118. Whether answers get more accurate was not measured.
The commands come from the strata-model helper script in the repository; Claude Code picks it up as a skill, other assistants can run it or read its output. Optional embeddings add search; local models send nothing anywhere.
One product, three ways to run it. Pick what fits how you work: the model files are the same.
Canvas, governance, impact analysis and version history inside VS Code 1.90 or newer.
Not on the Marketplace yet. Build it from source (about a minute): you need Node.js and VS Code with the code command.
git clone https://github.com/OWNER/REPO.git
cd REPO
npm install
npm run install-extstrata-sql for terminals and scripts: create projects, import dbt or SQL, split by domain, and open the editor in your browser with strata-sql live. Needs Node.js 20 or newer.
Not on npm yet: the package is built and tested. Until then, npm link in a source checkout gives you the same command.
strata-sql --help lists every command; the docs explain them.
npm link # once, in the cloned repository
strata-sql init --template northwind
strata-sql live # opens the editor in your browser
strata-sql live --demo # or: try the sample models, nothing is savednpm install -g @stratasql/strata-sql
strata-sql live
strata-sql live --demo
# or without installing
npx @stratasql/strata-sql liveThe image installs the same npm package and serves the browser editor over HTTP. Your project folder is mounted at /data.
Not published yet: the image is built and tested but not pushed. The commands here are what will work.
The server speaks plain HTTP and the link's access token is its only protection, so publish the port to 127.0.0.1 only, or put your own TLS and login in front. Details in the docs.
# try the sample models: nothing is saved
docker run --rm -p 127.0.0.1:8787:8787 -e STRATA_DEMO=1 OWNER/strata-sql
# or work on your own project
docker run --rm -v "$PWD":/data OWNER/strata-sql init --template northwind
docker run --rm -v "$PWD":/data -p 127.0.0.1:8787:8787 OWNER/strata-sqlOpen the link the container prints (docker logs); it ends in an access token. STRATA_DEMO=1 needs no folder: it opens the samples and keeps nothing.
No. VS Code is one way to run it. The same editor also runs in your browser: strata-sql live (needs Node.js) or the Docker image. An interactive HTML export needs nothing to open. There is no cloud or hosted version.
As a single-user editor, yes. The Docker image installs the same npm package and serves the browser editor over plain HTTP, with your project folder mounted at /data. The link's access token is its only protection, and there are no accounts or live co-editing, so publish the port to localhost only, or put your own TLS and login in front.
Yes. strata-sql live --demo, or the Docker image with STRATA_DEMO=1, opens the sample models (Northwind, FpML and a small star schema) for anyone to explore: every level, governance, impact analysis and version history. Nothing is saved: your changes stay in your browser tab and are discarded when you close it. How it works.
The Apache License 2.0, for the extension, the npm package and the Docker image alike. The licence text is the LICENSE file in the repository.
It needs dbt's compiled target/manifest.json (run dbt parse); it does not read dbt_project.yml or model YAML on their own. Column types are mostly generic (STRING) until a catalog.json exists. SQL that macros generate can give fewer columns, never invented ones. Ephemeral models, packages, exposures and some metric types are skipped and reported. It cannot import into a project already split by domain.
Yes, from SQL files, not from a live connection. Give it a schema dump or your CREATE TABLE scripts (PostgreSQL, MySQL, SQL Server, Oracle, Snowflake, BigQuery, Databricks, Trino, SQLite, DuckDB, Redshift) and it builds the physical model with keys and relationships; query files add starter metrics and lineage. Stored procedures are listed, not read, renames are not followed, and it has been tested on hand-written samples rather than real production dumps. Dump the schema first, for example with pg_dump --schema-only.
Measured on generated models: comfortable to about 1,000 tables, usable to about 2,000, sluggish at 5,000. Splitting by domain keeps each part small.
Not live. You work in Git: the model is plain JSON and the version log merges without conflicts. There are no comments inside the editor.
No, unless you turn on hosted embedding providers with your own key: then names and descriptions (never sample data) are sent after a confirmation. Local embedding models send nothing.
No. Strata SQL edits a model of your tables and can generate starter pipeline code (and, with the helper script, DDL) from it. It does not connect to a database.