A new open-source tool called sqlsure wants to solve a problem that’s been quietly growing as AI writes more of our database queries: SQL that runs perfectly and returns the wrong number anyway. The project launched as a Show HN post on Hacker News, where it climbed to 162 points. What stands out here is the pitch. A query can be valid, error-free, and still silently wrong, and sqlsure claims to catch that deterministically in about 0.1 milliseconds, before the query ever runs.
This matters because the failures it targets are the kind nobody notices until a report is already wrong. Revenue double-counted by a join. An average that got summed. A patient identifier exposed in the output. As the Hacker News post puts it, “Databases don’t catch this. Linters don’t catch this. LLMs reviewing their own SQL don’t catch this.”
What sqlsure actually does
Instead of running the query or calling a model, sqlsure parses the SQL text and checks it against facts your team has already declared. Think dbt tests, primary/foreign key relationships, or one-line tags marking which columns are safe to sum. The checks are dictionary lookups, not LLM calls, so the same input always produces the same verdict.
Here are the core rules it enforces:
- FANOUT and CHASM errors catch the classic double-counting traps, where a SUM or COUNT runs after a one-to-many join, or two fan-out joins multiply each other.
- ADDITIVITY and SEMI_ADDITIVE errors flag summing things that shouldn’t be summed, like rates, averages, or account balances across a snapshot dimension.
- JOIN_KEY and CROSS_JOIN errors catch joins on columns matching no declared relationship, or joins with no predicate at all.
- SENSITIVE_COLUMN policy flags PHI or PII columns showing up in query output.
Every rejection ships with a machine-actionable fix, which is the part built for AI agents. The loop is draft, check, fix, check, execute. In the project’s own benchmark, applying the suggested fix verbatim produced a passing query 10 out of 10 times.
The proof they’re leaning on
sqlsure ran itself over the gold-standard answers of Spider and BIRD, the two benchmarks nearly every text-to-SQL model is graded against. Across 2,568 expert-written queries, it raised 45 flags with zero false alarms. According to the post, one of those flags exposed a BIRD gold answer that is “provably wrong by 8x” from exactly the bug class sqlsure targets, plus a schema defect now filed upstream.
That’s a sharp move. When your tool finds real errors in the benchmarks people use to score everyone else, the claim gets harder to wave away.
How you’d use it
The tool ships in three shapes:
- CI gate that blocks a merge and exits with an error when a pull request double-counts.
- MCP server so an AI agent has to pass inspection before it executes anything. It plugs into Claude via a single
claude mcp addcommand. - Library you embed with a
check()call inside any text-to-SQL product or agent framework, including drop-in wrappers for Vanna and WrenAI-style generators.
The rulebook can come from dbt manifests, plain PK/FK declarations, or the live database catalog itself through introspection. No semantic layer required.
The honesty angle
One design choice deserves a callout. When sqlsure can’t verify something, it says “can’t verify,” never “looks fine.” Treating uncertainty as a feature rather than papering over it is the right instinct for a tool meant to sit in front of production queries.
On privacy, the project is aggressive: offline, zero network calls, no database connection (it only reads query text), no telemetry, and just two runtime dependencies shipped through PyPI Trusted Publishing.
Why it’s worth watching
As teams wire text-to-SQL agents into real workflows, execution accuracy stops being enough. A query that runs is not a query that’s correct, and that gap is exactly where sqlsure plants itself. It’s licensed under Apache-2.0, so it’s free to try today.
The roadmap points at Cube and Snowflake Semantic View adapters next. Full details and the 30-second demo are available at the original source.