Skip to main content

Your product shouldn't need a SQL compiler team.

43 dialects from one grammar. 100.0% pass rate, column lineage, type inference, dbt and Jinja. License it instead of hiring for it.

You've probably been here before.

Your product touches SQL somewhere: lineage, catalog, security, migration, ELT, IDE, agent. You didn't set out to build a SQL compiler. But you ended up maintaining a parser anyway. Regex for the 80% case, a licensed parser for the hard 20%, and a backlog of "Trino silently falls back to PostgreSQL" issues that nobody gets around to fixing.

The two realistic open-source alternatives both changed hands. SQLGlot is now owned by Fivetran, SDF by dbt. If you ship a data product, that's either a strategic problem or a reminder that SQL parsing was never your core business.

We built the replacement.

Two compiler engineers, full-time. One grammar that generates parsers for 43 SQL dialects. Not a prototype: a validated, shipping system.

43
SQL dialects
From one grammar
613,988
identity tests
From 37 independent sources
100.0%
pass rate
Parse, render, same text
95,190
models and files parsed
163 public dbt projects, and 989 SQL corpora in 15 dialects

Parsing is the floor. On top of it: column-level lineage, type inference, query optimization, error recovery, SQL formatting, and a full dbt/Jinja pipeline.
See the live playground, benchmarks, and grammar →

The scope, in engineering terms.

Not every team should build this from scratch. Here's what a from-scratch implementation actually looks like.

Time3 to 5 years of compiler-engineering work before you have something ready for production
TalentCompiler engineers who understand SQL dialects at the grammar level are rare. Most teams spend months trying to hire one.
ScopeGrammar IR, code generation, 43 dialect grammars, 8,283 AST types, scope resolution, type inference, column lineage, query optimization, error recovery, dbt integration, SQL formatting. Each piece depends on the others.

If your team isn't six compiler engineers deep, this is a buy-vs-build decision you've probably already made.

dquery is not open source.

And we are not planning to make it so. Partners get what they need to ship on it: the binaries, the API, the dialects they run, a say in the roadmap — and source access where the licence calls for it. dfmt, built on the same engine, is free for anyone.

How to get it

Integration partnership

Embed the parser, AST, and lineage engine inside your product. Non-exclusive. Good fit for catalogs, platforms, and tools that depend on SQL quality but don't need category exclusivity.

  • All 43 dialects out of the box
  • Grammar stays on our roadmap, not yours
  • Custom dialect extensions available
  • Revenue-shared or flat-fee terms

Typically replaces Manta / IBM, Apache Calcite, Gudusoft GSP, SQLGlot, sqlparser-rs, or a homegrown ANTLR grammar.

Exclusive license

Category-exclusive access, for companies that can't share SQL infrastructure with a competitor. OEM and redistribution rights, full source access, white-label permitted.

  • Category-exclusive terms available
  • Full source access
  • OEM and redistribution rights
  • Custom dialect extensions
  • Priority support and roadmap input

Licensing is selective.

We work with a small number of companies at a time. If the fit looks right, send us a note.

Get in touch