Best for
- The query feeding a decision, checked before the decision
- Analysts' SQL that is correct on the sample and wrong at scale
- The report that 'looks off' and needs its logic audited
What you give it
- The query, the question it is supposed to answer, and access to the schema (data access helps but is optional)
What you get back
- The correctness audit: where the query's logic diverges from its stated question — fan-outs, filter placement, null traps, time-zone edges
- The performance read: how this executes at real sizes, and the rewrites that keep the answer while fixing the cost
- The corrected query with the differences explained — so the lesson travels beyond this one query
How it works
- Audits against the stated question, clause by clause: grain in, grain out, what each join does to row counts, what each filter excludes — including what it excludes by accident.
- Hunts the classic silent killers: fan-out joins counted as facts, WHERE-filters that defeat LEFT joins, NULL comparisons that drop rows, DISTINCT papering over a join bug, time zones and date boundaries.
- Reads the execution reality: the plan where available, the anti-patterns (functions on indexed columns, leading wildcards, correlated subqueries at scale) where not.
- Returns the corrected query with each change explained — review that does not teach gets repeated.
Example
You: Review the churn query behind next week's board number.
Result: Two correctness findings that changed the number: the join to subscriptions fans out for customers with multiple plans (the count was counting plan-rows, not customers — fixed with pre-aggregation; the churn rate moved from 7.2% to 5.8%), and the left join's filter in the WHERE clause silently converted it to inner (the never-subscribed cohort vanished — moved to the join condition). One performance finding: the date function wrapped around the timestamp column defeated the index (rewritten as a range; 40s to 0.8s). The board got 5.8%, with the audit note attached.
Limits — please read
- Verification against data needs data access; without it the audit is structural (and says so).
- The stated question must actually be stated; 'is this query right' without the question gets the question asked back.
- Dialect specifics are checked for the engine you name.