Block dangerous SQL before it runs.

The Problem

One "small" SQL change:

- WHERE created_at > DATEADD(day, -30, CURRENT_DATE)

That's a removed filter on a DELETE. If that slips through code review, production data is gone. One red line in a git diff is easy to miss—especially in large PRs with many changed files.

At 50+ dbt models, no one has the time to review SQL carefully. PRs get approved with "LGTM" and hope, until production is affected.

What Lexega Catches

In a dbt project:

$ lexega-sql review main..HEAD models/ -r

Decision: BLOCKED (exit code 2)

Signals:
CRITICALDIFF-WRITE-WHERE-RMV: Unbounded Write After WHERE Removed
models/staging/stg_events.sql — DELETE lost WHERE clause, may affect entire table
HIGHDIFF-JOIN-NARROW: JOIN Type Narrowed
models/marts/fct_orders.sql — LEFT → INNER JOIN, may silently drop rows

In a migrations or infrastructure repo:

$ lexega-sql review main..HEAD migrations/ -r

Decision: BLOCKED (exit code 2)

Signals:
CRITICALMASK-DROP: Masking Policy Dropped
migrations/cleanup.sql — Column data protection removed
HIGHGRT-ALL-PRIV: Grant All Privileges
migrations/permissions.sql — Use specific grants, not ALL PRIVILEGES

Signals are informational. In CI/CD, a policy produces a decision artifact (and exit code) you can gate on—before it reaches production.

How It Works

Lexega turns SQL diffs into actionable risk: understand what changed, classify the impact, and enforce policy automatically.

1. 1
   Render — Jinja templates and dbt macros are evaluated natively—{{ ref('orders') }} becomes the actual table reference—without Python or dbt installed
2. 2
   Parse — The parser reads Snowflake, PostgreSQL, BigQuery, and Databricks natively
3. 3
   Extract — Signals are emitted as it reads the SQL: tables read/written, join types, filter predicates, column lineage
4. 4
   Compare — On diff / review, it compares semantic models between branches—not text, but meaning
5. 5
   Classify — Signals are assigned a severity level: removing a WHERE on DELETE is critical; adding a column is info
6. 6
   Report — A report of the signals is generated. Reports are formatted as plain text, JSON, YAML, or SARIF
7. 7
   Enforce — In CI/CD, policy bundles and JSON output allow automation: block merges, notify teams, trigger audits

Where It Runs

Same binary, same rules, same decision schema. The policy doesn't care who wrote the SQL—it evaluates the query and renders a verdict. CI writes the decision to a file for audit. Agent runtime writes it to stdout for immediate action.

lexega-sql review main..HEAD -r --pr-comment

lexega-sql analyze --stdin --mode runtime

Tested at Scale

We analyzed a 3,300+ model dbt project (GitLab’s public Analytics dbt repo) to stress-test detection at real-world scale:

123 critical-severity findings—JOIN changes, NULL logic hazards, filter removals—each one a potential incident that Lexega could have prevented.

These are detections from static analysis and semantic diff signals; your policy decides what blocks vs warns.

Adopt Without Noise

Drop Into Any Pipeline

# .github/workflows/sql-review.yml
on: [pull_request]
permissions:
  pull-requests: write
steps:
  - uses: actions/checkout@v4
    with: { fetch-depth: 0 }
  - run: lexega-sql review $BASE..$HEAD . -r --pr-comment
    env:
      LEXEGA_LICENSE_KEY: ${{ secrets.LEXEGA_LICENSE_KEY }}
      GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

# Exit code 2 = blocked, 0 = passed

Block PRs that violate policy with a single binary. No dependencies. Your rules, enforced automatically.

What's Included

Who It's For

Built first for data platform and analytics engineering teams who need to control what’s allowed to run in production—before it runs.

• ●Platform engineers adding policy gates to CI/CD pipelines
• ●AI/Agent developers needing guardrails on LLM-generated SQL
• ●Security teams needing pre-merge controls and audit evidence
• ●Data leads scaling beyond "everyone reviews everything"
• ●Compliance teams requiring decision records with cryptographic proof

Current Status

• ●Native Jinja/dbt rendering—no dbt installation required in CI
• ●Built-in detection rules for semantic diff and risk analysis
• ●Signal Detection and Policy engine with YAML config + JSON Schema validation
• ●Catalog integration for PK/FK relationships, row counts, and grant graph
• ●Locally hosted dashboard for leads and platform teams to track findings, policies, and exceptions over time

Get Started

curl -sSL https://lexega.com/install.sh | sh

Questions? support@lexega.com · We respond within 24 hours.