0sql documentation

0sql turns a query spec into one SQL statement for your warehouse. You describe tables, dimensions, measures, joins and row-level security policies in YAML, deploy the project with the zsql CLI, and your application sends requests like the one below. 0sql plans the SQL in microseconds and returns it. It never connects to your warehouse, never executes anything, and stores nothing about your queries.

POST https://app.0sql.io/projects/tpcds/branches/main/sql
Authorization: Bearer zqk_…
Content-Type: application/json

{"spec": {"projections": [{"field": "Category"}, {"field": "Web Net Paid"}],
          "filters": [{"field": "Category", "predicate": "starts_with", "value": "super"}]}}

{"sql": "SELECT\n\tT1.\"i_category\" AS \"Category\",\n\tsum(T0.\"ws_net_paid\") AS \"Web Net Paid\"\nFROM\n\tweb_sales T0\n\tJOIN item T1\n\t\tON T0.ws_item_sk = T1.i_item_sk\nWHERE\n\tLOWER(T1.\"i_category\") LIKE 'super%'\nGROUP BY\n\tT1.\"i_category\"",
 "datasource": "Warehouse", "datasource_uid": "warehouse", "adapter": "postgres"}

What 0sql does

• Resolves names to SQL. A request names fields, not columns. The planner finds the tables that hold them, the join route between them, and the aggregation each measure needs.
• Blends across fact tables safely. Measures from different facts at different grains are aggregated separately and stitched on the conformed dimension. No fan-out, no double counting. See cross-fact blends.
• Applies your security policies. Each request carries a security context. Policies in the model turn it into WHERE filters or CASE masks in the SQL. See security context.
• Speaks 13 dialects. One model, one request shape, SQL for Postgres, Snowflake, BigQuery, Databricks, Redshift, Athena, Trino, ClickHouse, Druid, DuckDB, MySQL, SQL Server or SQLite. See adapters.
• Refuses before it is wrong. A request that cannot be resolved returns an error naming what could not be found, with the nearest fields. See errors and corrections.
• Keeps your data inside your network. 0sql is given the shape of your warehouse, never its contents, and never opens a connection to it. See what crosses the boundary.

What 0sql does not do

0sql returns SQL. Your application runs it, caches it, renders it, charts it. There is no query execution, no result cache, no end-user UI, no dashboards and no saved queries. Views, reports and interactive filters belong to the caller; filters in a spec are plain values that your application has already resolved.

What crosses the boundary

0sql plans SQL from a description of your warehouse. It never holds a credential for it, never opens a connection to it, and never reads a row from it. Your data stays inside your own network.

Of the things that do cross, only the model is kept. A spec and its context are planned in memory and are never stored or logged, so there is no query history to leak and nothing to subpoena. The statement comes back to you, and you execute it yourself, against your own database, with your own credentials.

The practical consequence: a reviewer assessing 0sql is assessing access to your schema metadata, not to your data. See accounts and keys for exactly what is stored, and the privacy policy for the commitment in writing.

The journey

1. Get a key. Sign up at the console and create an API key. See accounts and keys.
2. Model. zsql init, describe your datasources, add tables and relations in YAML. See the semantic model reference.
3. Deploy. zsql deploy sends the project to the service. The checked-out git branch becomes the deployed branch. See deploying.
4. Request. POST a spec with a security context and get SQL. See the Query API.
5. Run it. Against your own warehouse, with your own credentials, in your own code. The data never moves.

The quickstart does all five in about ten minutes.

Where to go