If you've ever reviewed a SQL PR where "the diff is bigger than your screen", you already know the failure mode:
the change looks reasonable,
tests pass,
but a single dangerous statement slips through because nobody can realistically inspect everything.
Lexega is built around a simple idea: turn SQL into deterministic, actionable "signals" before it runs, then use policy to decide what to do with those signals. It's a guardrail layer for SQL -- a structural analysis engine that sits between "code written" and "code deployed".
This post is a quick tour of what actually happens under the hood when you run lexega-sql analyze .
The pipeline: SQL → semantics → signals
At a high level, Lexega does four things:
Tokenize and parse your SQL (including multi-statement scripts and Jinja/dbt templates) Walk the AST to extract semantic facts -- tables read/written, grants, policy changes -- and emit categorical signals that describe what actually happened Match rules (builtin + custom YAML) against those signals to assign severity and messaging Evaluate policy to produce a decision (block, warn, or allow)
You can think of it like this:
... continue reading