How to Compare Two SQL Queries (SQL Diff)

You've edited a report query, tweaked a migration, or picked up a change in a pull request, and now you need one thing: what actually changed between these two queries? A generic text diff can answer that — badly. SQL Compare answers it well, because it understands that formatting isn't meaning.

Try the examples in SQL Compare — like the rest of the toolkit, it runs entirely in your browser.

The problem with a plain text diff

Suppose these two queries are logically identical — only the whitespace and casing differ:

-- Original
select id, name from users where active = 1

-- Modified
SELECT
  id,
  name
FROM users
WHERE active = 1

A plain text diff would scream that every line changed. That's noise: nothing about the query's behavior is different. You'd waste time reading a diff that has no real content.

The fix: normalize before comparing

SQL Compare's key feature is the Normalize option (on by default). Before diffing, it runs both sides through the SQL formatter using the dialect you pick. Now the two queries above format to exactly the same thing, so the tool reports them as identical — no false differences at all.

This means you only ever see differences that survive formatting — i.e. real, structural changes to the query. Turn Normalize off when you specifically want a literal, character-for-character comparison of the raw text.

A real difference shows clearly

Now compare two queries that genuinely differ — a column was added and the filter changed:

-- Original
SELECT id, name
FROM users
WHERE status = 'pending'

-- Modified
SELECT id, name, email
FROM users
WHERE status = 'shipped'

SQL Compare highlights the changed lines: the SELECT line and the WHERE line, with the removed version in red and the added version in green. A +N / −N badge summarizes how many lines were added and removed.

Side by side vs unified

Two views, pick whichever reads better for the change at hand:

• Side by side — original on the left, modified on the right, aligned line-for-line. Best for wide screens and for seeing a changed line next to its replacement.
• Unified — a single column with removed (−) and added (+) lines interleaved, like a Git diff. Compact and familiar for code review.

Narrow the diff further

Two extra switches let you decide what counts as a difference:

• Ignore case — treats WHERE and where as equal. Useful when only casing changed and you don't care.
• Ignore whitespace — ignores indentation and spacing changes during the comparison.

Combined with Normalize, these let you focus purely on the structural shape of the query and filter out cosmetic edits entirely.

When it isn't valid SQL

If Normalize is on and one side can't be parsed as the selected dialect (a work-in-progress query, or a snippet rather than a full statement), that side is compared as raw text instead, and a small notice tells you so. You still get a useful diff rather than an error.

Where SQL Compare helps

• Reviewing migrations — confirm a hand-edited migration matches the intended change.
• Pull-request review — see the real difference between two versions of a report or view.
• Refactoring — verify that a rewritten query is equivalent (identical after normalization) or spot exactly where it diverged.
• Debugging — compare the query your ORM generated against the one you expected.

Everything stays local

Both queries are compared in your browser. Nothing is uploaded, so it's safe to paste production queries, internal schema names, or anything sensitive.

Pair it with the formatter

Comparing is the review step; formatting is the cleanup step. If you also want to tidy a single query — control its casing, indentation, and layout — read How to Format SQL: A Complete Guide or open the SQL Formatter.