The same grammar that powers our JVM compiler, emitted to native code and WebAssembly. Performance: 18.4× faster than PostgreSQL's own parser. Precision: 50,804 of 50,806 parse tests pass — just 2, both invalid SQL. One declarative grammar, no rewrite per target.
15 PostgreSQL files, 20,000 iterations, Apple M5 Pro. Each parser runs in its own process against the same input, and every one parses all 15 queries. Lower microseconds is better — and libpg_query is the parser that ships inside PostgreSQL itself.
Numbers represent parse-only time. Tokenization, AST construction, and memory allocation are all included. The Datoria parser uses an arena allocator: "arena reuse" mode reflects the steady-state cost in a long-running server; "fresh arena" mode reflects per-request cost when the allocator is rebuilt every call.
The same parser, compiled to a 669 KB WebAssembly module — no server, no API call. Edit the query, hit Parse, or load a deliberately gnarly one with Complex query (recursive CTE,FILTER, WITHIN GROUP, GROUPING SETS,DISTINCT ON, windowed frames, LATERAL). Then run the benchmark and watch it parse thousands of times a second, live in this tab.
The PostgreSQL parser fits in a static binary the size of a JPEG, and a WebAssembly module that compresses smaller than a font file.
macOS arm64, ReleaseFast. Linux x86_64 and aarch64 ship from the same build script.
Gzipped for the wire (3.4 MB raw). The exact module powering the live demo above — parses PostgreSQL inside the browser, edge runtime, or any WASM host.
Parse-only against the same PostgreSQL corpus as the JVM build. 2 failures, both invalid SQL.
The parser is generated by a code generator that consumes a language-agnostic IR. The same IR already produces Java; the new backends add Zig, WebAssembly, and Rust without touching the grammar.
Statically linked, no runtime, no garbage collector. Single-pass arena allocation. Cross-compiles to every platform Zig targets.
669 KB gzip over the wire. Runs in Node, Deno, Bun, Cloudflare Workers, Vercel Edge, and any modern browser. JS bindings included.
Same parser, idiomatic Rust output. Slot into existing Rust stacks without the FFI boundary that pg_query and tree-sitter wrap.
A SQL parser is a translation of a grammar into code. Most parsers marry the two: the grammar lives inside the parser, and porting to a new language means rewriting both. Our compiler keeps them separate. The grammar is a data structure; the code generator walks it; the output is the parser.
That separation is why the same PostgreSQL grammar that drives the JVM build also drives the Zig build. Same 50,806 identity tests, same 2 failures, same lossless roundtripping. The Zig backend is roughly 3,983 lines of code generator producing 127,320 lines of Zig — a 32× amplification ratio that makes adding the next target a tractable project rather than a yearlong fork.
Performance comes from the structure. There is no interpreter, no virtual dispatch, no boxed AST nodes. Every parse method is generated directly from the grammar rule. Tokens are tagged integers. The AST is laid out in a single arena. The hot path is straight-line code.
The native parser will be open source. We're getting the first integrations right before opening the doors. If you ship a product that touches PostgreSQL parsing — a data tool, a SQL editor, an AI agent, an edge runtime — we'd like to hear what you're building.