Today 0sql goes open source under the MIT licence. The planner, thirteen SQL dialects, the zsql command line and the server your applications and agents call, in one static binary.
curl -fsSL https://0sql.io/install.sh | sh
zsql init myproject && cd myproject
zsql serve
That is a running semantic layer on your machine, and I think it is the most capable one you can get your hands on. The source is at github.com/stratasite/0sql.
Why this matters now
The semantic layer is the part of analytics that makes the numbers right. It knows what “revenue” means, which tables join to which, at what grain each measure aggregates, and which rows a given person may see. For years it lived inside BI tools. Then agents arrived, and suddenly everyone building on a warehouse needs that layer in the loop, because a model that writes its own SQL joins the wrong way, double counts across fact tables, averages an average, and forgets the security filter just often enough that nobody will ship it.
There are open source semantic layers already, and Cube and MetricFlow are good ones. What I wanted was one that could answer more of the questions people actually ask, straight from the model, without a modelling ticket for every new shape of question. That is what 0sql is, and from today it is free for everyone: the solo developer with an internal tool, the startup putting “ask your data” in its product, the data team that wants every agent in the company reading through one governed model.
What you get
One request, two fact tables, a shared date:
zsql sql --expr "web net paid, web sold date, net paid"
WITH ag29130fae5cf6548d6ddb1bd37298b407 AS (
SELECT
sum(T0."ws_net_paid") AS "msr501e4a8",
T0."ws_sold_date_sk" AS "dimed56b67"
FROM
web_sales T0
GROUP BY
T0."ws_sold_date_sk"
), ag7098b0d0901f2eb16d14f9356f0bb2a0 AS (
SELECT
T0."ss_sold_date_sk" AS "dimed56b67",
sum(T0."ss_net_paid") AS "msr621f67c"
FROM
store_sales T0
GROUP BY
T0."ss_sold_date_sk"
)
SELECT
A0.msr501e4a8 AS "Web Net Paid",
COALESCE(A1.dimed56b67, A0.dimed56b67) AS "Web Sold Date",
A1.msr621f67c AS "Net Paid"
FROM
ag29130fae5cf6548d6ddb1bd37298b407 A0
FULL OUTER JOIN ag7098b0d0901f2eb16d14f9356f0bb2a0 A1
ON A1.dimed56b67 = A0.dimed56b67
Each fact aggregated at its own grain, stitched on the conformed date, nothing double counted. Nobody modelled that query. The planner derived it from three table definitions and two joins, in about 70 microseconds. That is the baseline, and here is what sits on top of it that you will not find together anywhere else:
Modelling that goes further.
Measures from any number of fact tables in one statement, with no fan-out and no hop limit.
Any SQL aggregate as a measure, not a fixed list of aggregation types.
Compound measures whose formula spans facts, levelled automatically.
Snapshot measures: beginning or ending balance per period, for inventory, balances, headcount.
Exclusion and inclusion level of detail in the model: percent of total, fixed denominators, aggregate per entity and then re-aggregate.
Partition-aware and aggregate-aware routing to the cheapest table you already own, across tiers and even across compute engines.
Analysis in the request, not a modelling ticket.
Period over period, running and moving windows, and month or quarter grains are decorators on a projection.
Top-n is a filter. Cohorts are segments you can apply to one measure beside the baseline, or exclude.
Formulas over any measures, right in the request, with nothing to deploy first.
A one-line shorthand for people at a prompt:
month(date), yoy(revenue), category = produce.
Governance you can prove.
Row-level security policies in the model become
WHEREpredicates andCASEmasks in the statement, from the caller’s context. A branch with policies refuses to plan without one.Deterministic output: same spec, same SQL, byte for byte, so you can pin a statement in a test and a deploy fails when it drifts.
Git branches deploy as branches, so a model change gets reviewed like code.
Built for agents.
A refusal names what could not be resolved and the nearest fields, so an agent fixes its spec on the next turn instead of guessing.
Explore and field search tell an agent what a query can still add.
An MCP endpoint in the same server: point Claude Code or any MCP client at it and the catalogue and the planner are tools.
One
llms.txtwith the whole guide for the agent writing the model.
Thirteen dialects: Postgres, Snowflake, BigQuery, Databricks, Redshift, Athena, Trino, ClickHouse, Druid, DuckDB, MySQL, SQL Server and SQLite. One model, one request shape, the right SQL for each.
A model that carries the meaning, not just the names
There is now an open standard for describing semantic models: Apache Ossie, formerly Open Semantic Interchange, started by Snowflake and Salesforce and incubating at Apache since June. Twenty converters already translate between it and dbt, Databricks, Cube, Power BI, Sigma and the rest. I think it is good for everyone that a common document exists, and 0sql is going to read and write it.
But look at what the document holds. Datasets, scalar fields, metrics as aggregate SQL strings, and relationships that are foreign-key equi-joins with no cardinality, no join type and no condition beyond column equality. Every converter publishes a list of what it drops on the way through, and the lists are the same: cardinality, grain, security, non-equi joins, cumulative and period-over-period metrics. Ossie carries the definitions. It does not carry the things that decide what SQL comes back.
0sql’s model carries exactly those. Measured concept by concept against the specification, it is a superset on everything that determines the statement, and the gap is the planner’s worth of semantics Ossie’s own roadmap lists as open work: dataset-level measures, explicit cardinality, entity and grain, semantic filters, cumulative metrics, and “a semantic query language and reference engine” under Future.
The two formats are not rivals, and that is the exciting part. Next on the roadmap is zsql ossie import and export: hand 0sql the document Snowflake generates from a semantic view with one system function, and get that model planned, with fan-out safety and policies added, for every other warehouse you own, with a loss report naming anything that could not be carried. Export goes the other way, with the extra semantics in the extension slot the spec provides. The same model format is what Strata runs on, so it is already proven. We will contribute the converter upstream and bring these pieces to the working group as proposals, each already implemented and tested. The open standard says what a metric is called. 0sql is the engine that says what it means.
Why open source
A few weeks ago, launching Strata on Hacker News, I wrote that a semantic layer is “definitely not useful for developers” any more. Agents changed my mind about where it belongs: wherever a model composes reads over governed data, which is soon to be everywhere. Infrastructure that everyone builds on should be something everyone can read, run and fix. Strata, our full platform, runs on the same planner and the same model format, so a model you write for 0sql today is one Strata can run tomorrow. We make our living on the platform. The layer is yours.
Run it
The quickstart goes from an empty directory to SQL in ten minutes, and Running the server covers accounts, keys and systemd when you share it with a team. The live playground plans against two sample models in your browser, and the chat dashboard demo is a complete app where a model writes the spec and 0sql plans the SQL, with a 34-minute walkthrough.
Then tell me what would not fit. What you tried to model and could not, what you had to write around, where you stopped. Open an issue or write to info@strata.do; a spec that would not resolve goes straight into the planner’s tests. Star it if it is useful. Fork it if it is not quite. That is the point.