Let’s be honest: LLMs are pretty good at writing SQL until they aren’t. They’ll give you something that looks right, runs fine on your test data, and then silently does the wrong thing in production because it joined on the wrong column or generated a syntax that your database vendor doesn’t support. For a dev tool, that’s annoying. For an enterprise, it’s a compliance nightmare.
A new paper (arXiv:2607.11951) introduces GRID — Grammar-Railed Decoding — and it’s the most practical approach to enterprise SQL generation I’ve seen in a while. The idea is elegant. Instead of asking the LLM to generate SQL and hoping it gets the syntax right, you lock the generation into a grammar from the start. Every token the model produces is checked against an LALR(1) parser before it’s emitted. If the token would produce invalid SQL, it’s blocked. The model doesn’t get to make syntax errors.
How it works (the simple version)
GRID keeps a running parser state as it generates each token. Think of it like autocomplete that can only suggest valid continuations. The system builds a trie over the grammar’s terminals, bridges LLM tokens to those terminals, and uses the actual parser state — not just the token history — as the cache key for what’s allowed next. That means the mask of valid next tokens is provably correct.
The clever part is role-based access control gets compiled directly into the grammar. If a user role isn’t allowed to run DELETE statements, the grammar simply doesn’t have that production for them. The model can’t generate “DROP TABLE customers” because the mask never allows the token sequence. It’s not a guardrail bolted on after generation. It’s baked into the generation itself.
The numbers
GRID runs in 3.6 to 6.7 microseconds per token — that’s fast enough that you won’t notice it’s there. On the Spider benchmark, constrained decoding added 13 execution-accuracy points at 0.5B parameters. A single repair pass over the few things the mask can’t enforce (column-level policy) lifted a 7B model to 94.5% executable SQL. The audit trail is hash-chained and replays bit-identically with 100% tamper detection.
What it can’t do
The paper is refreshingly honest about limitations. The mask can’t fix distribution faithfulness — the model’s preferred SQL might still be weird SQL, just valid SQL. It can’t enforce column-level RBAC because column names are identifiers the grammar can’t subset at that granularity. And it only works for LALR(1) languages, which covers most SQL dialects but not all.
But for the use case — enterprise SQL generation where you need provable guarantees and a compliance record — this is a serious step forward. It’s not “ask an AI for SQL and hope”. It’s “ask an AI for SQL inside a cage where only valid, policy-compliant SQL can come out”. If you’re running any kind of natural-language-to-SQL tool in production, you want this approach.
Source: “GRID: Grammar-Railed Decoding for Enterprise SQL Generation” (arXiv:2607.11951)