dquery · the engine
An SQL compiler generated from one grammar: 43 dialects, defined once, declaratively. The generator emits the parser, the renderer and a full semantic layer — types, column lineage, optimisation — so your product does not need a SQL compiler team.
Dialects
43
Every common database, from one grammar.
Identity tests
469k+
Parsed, rendered and re-parsed byte for byte.
Roundtrip pass rate
99.9%
Across every dialect on the board.
Per file
44µs
Faster than the Rust and C parsers we measured.
What it is
Not a hand-written parser, and not a wrapper around a database. SQL is described once as pure data — a declarative grammar — and a code generator emits the entire engine from it. That architecture is where the performance and the precision come from.
Every SQL construct is written once as pure data — no code, no functions — so the whole grammar can be analyzed statically. 43 dialects share it through inheritance: PostgreSQL extends ANSI, DuckDB extends PostgreSQL. Adding the next one is a grammar change, not a new parser — which is why coverage keeps growing.
The grammar is the source of truth. A language-agnostic code generator reads it and emits the entire parser, lexer, typed AST, and renderer — none of it hand-written. Today it’s a Java library, callable from any JVM language; Rust is next, with Python and TypeScript wrappers likely to follow.
Above the parser: scope resolution, type inference, column-level lineage, and a multi-pass optimizer — all dialect-agnostic. Parse PostgreSQL, analyze it neutrally, render it as Snowflake.
A JVM library that out-parses native code: 2.6x faster than sqlparser-rs (Rust) and 5.0x faster than libpg_query, the C parser inside PostgreSQL. Generated code, not interpreted — zero backtracking, with dispatch trees computed statically from the grammar.
Lossless roundtripping: parse and re-render byte-for-byte, every token preserved — keywords, punctuation, even whitespace and comments.
Try it
Edit the SQL below. The analyzer returns inferred types (with nullability, VARIANT, and struct types), column-level lineage through CTEs and JOINs, and the full typed AST. Switch dialects to see how parsing differs.
What you can build
The hard part — reading SQL precisely, across 43 dialects, with types and lineage — is done. Anything that has to read, check, transform, or trace SQL becomes a product you can build on top. A few of the directions it opens:
Give an agent real tools for SQL: a column’s full lineage to reason about a query, formatting, and verification of the SQL it generates — checked before it ever runs.
Datoria parses every major dialect today — Snowflake, Redshift, BigQuery, MySQL. Migration becomes paste-and-go for your users, not a six-month consulting engagement.
Stitch every transformation — raw, templated, or dbt — into one typed graph. Trace any column end to end, and catch type and breaking changes before they ship.
Which of last week’s 80,000 queries touch users.email? Seconds, not a manual audit. Pattern mining, regression detection, and BI lineage all fall out of it.
Column-aware autocomplete, semantic errors, jump-to-definition. The understanding layer ships today — wire it into VS Code, JetBrains, or your own IDE.
Before a migration applies, flag the views that will break, the policy referencing a renamed column, the ALTER that isn’t type-compatible. Before, not after.
The first product built on it is dfmt, our free SQL formatter.
The coverage board
A box is not a demo — it is a complete SQL dialect, DDL through window functions through vendor quirks, proven by parse → render → re-parse roundtrips on its own corpus — including the official PostgreSQL and Google ZetaSQL compliance suites. A line groups dialects sharing one grammar; +N engines are the compatible services each also answers as. Green means 100%.
Performance
22.9x faster than SQLGlot. No backtracking, linear time, JIT-friendly generated code.
1000 iterations, 15 files, Apple M1 Max.
The stack
Nine layers, each generated from the same declarative grammar. Nothing below is a separate tool bolted on — it is one compiler, and every stage sees the same typed tree.
One grammar definition with dialect predicates. Pure data, no embedded functions.
Generates parser, lexer, 5,480 immutable typed AST interfaces, and a renderer per dialect.
Full Jinja evaluator with ref(), source(), var(), config(). Compiles 164 public dbt projects (26,943 models) end-to-end.
Fully qualified references across nested CTEs, subqueries, and lateral joins.
20+ rule types, 134 function signatures, dialect-aware coercion, nullable tracking.
One-pass DAG traces columns through JOINs, CTEs, window functions, and star expansion. Tested across 164 public dbt projects (26,943 models).
Partial parses with precise error positions. Never crashes on broken or incomplete SQL.
15-pass pipeline: qualify, simplify, pushdown, unnest, merge, eliminate.
Adaptive formatting with trivia-signal detection. 20 config options, Jinja-aware.
dbt & Jinja
We don't shell out to dbt or rely on regex. We wrote our own Jinja parser, evaluator, and dbt project loader, because you can't analyze a template you can't evaluate.
A purpose-built Jinja engine with its own generated parser (same grammar IR as the SQL parser). Handles macros, filters, control flow, and nested expressions, with proper scoping.
Reads dbt_project.yml, resolves ref() and source(), loads seeds and schemas, and builds the DAG. Every model is compiled to pure SQL, then parsed, type-checked, and traced for lineage.
dbt-utils, dbt-expectations, and the core adapter macros for Snowflake, BigQuery, PostgreSQL, Redshift, Spark, Databricks, and more. Each project declares its dialect, and the matching parser handles the compiled SQL.
Some dbt macros call the warehouse at build time (run_query, execute). We analyze the SQL they intend to run statically, so your pipeline doesn't need live database credentials.
Grammar
Every SQL construct is defined once in a declarative grammar, with dialect predicates picking the variants. Click any element to drill in. Switch dialects to see how the syntax varies.
Comparison
The other open-source SQL compilers — SQLGlot, SDF, SQLMesh — are now owned by Fivetran or dbt. Datoria is the one that isn't, and the only engine pairing this dialect breadth with full semantic analysis.
| Datoria | SQLGlot Python, Fivetran-owned | SDF/Fusion Rust, dbt Labs-owned | Calcite Java, Apache | jOOQ Java, commercial | |
|---|---|---|---|---|---|
| SQL dialects | 43, growing | 24+ | 4 | 1 (ANSI) | 20+ |
| Parse speed | 44µs | 999µs | — | 221µs | 103µs |
| Roundtripping | Lossless | Lossy | Lossy | Lossy | Lossy |
| Typed AST | 3k+ shared + 1k+ dialect types | Untyped dict | Rust structs | Java classes | Java DSL |
| Column lineage | Yes (O(n)) | Limited | Yes | No | No |
| Type inference | Dialect-aware | Limited | Yes | Yes | Yes |
| dbt / Jinja | Built-in | No | Built-in | No | No |
| Error recovery | Yes | No | No | No | No |
| SQL formatter | Adaptive | Basic | No | No | No |
| Independence | Yes | Fivetran | dbt Labs | Apache | Data Geekery |
Try the formatter now. If you want the full engine, we're opening early access to a small number of companies, so get in touch.