Do these two queries return the same thing?
The only honest answer comes from execution. Diff mode runs query A and query B against identical fresh databases and compares the result multisets — row-level differences, order sensitivity, and column mismatches included.
press RUN (or Ctrl+Enter) — everything executes in your browser, nothing is uploaded
When you need this
You rewrote a correlated subquery as a JOIN. You replaced NOT IN with
NOT EXISTS. You "simplified" a WHERE clause. An optimizer-friendly rewrite is only a
win if it returns the same rows — and eyeballing SQL is a notoriously bad equivalence checker
(so is asking an LLM: semantic equivalence of SQL is undecidable in general, which is precisely
why this tool executes instead of reasoning).
How the comparison works
Both queries run against identical fresh in-memory databases built from your schema and seed
rows. Results compare as multisets — row order doesn't matter unless both queries use
ORDER BY, in which case order divergence is reported separately (order_differs).
Differing rows are listed as "only in A" / "only in B" (capped at 50 each). Column name or count
mismatches are reported before row comparison.
The classic gotcha this catches
NULL handling in NOT IN. The preloaded example above rewrites
WHERE id NOT IN (SELECT order_id FROM returns) as NOT EXISTS — a
textbook "equivalent" refactor. Press RUN: they differ. The returns table contains a NULL
order_id, and NOT IN against a set containing NULL is never true
(three-valued logic), so query A returns zero rows while the NOT EXISTS version returns what the
author actually meant. This exact bug ships to production constantly; executing both queries on
data with a NULL catches it instantly.
FAQ
Does row order matter in the comparison?
No — results compare as multisets (duplicates counted). If both queries have ORDER BY and the sequences differ while the sets match, that is reported separately as order_differs.
Can it prove two queries are equivalent for ALL data?
No — execution proves (in)equivalence on the data you provide. That is the honest limit; general SQL equivalence is undecidable. Seed edge cases (NULLs, duplicates, empty tables) to strengthen the check.
What data do the queries run against?
Each query gets its own fresh database built from the same schema and seed rows, so a write in query A cannot contaminate query B.
Is there an API version for agents?
Yes — the diff_results tool on the sqlai.dev MCP endpoint does exactly this, priced per call.
Related: Test SQL without a database · MCP SQL verification for AI agents · Run SQL online (SQLite)