Diff SQL Queries Online: Find What Changed in Your Migrations

A migration that drops a column, renames a constraint, or quietly changes a default value can ruin a production deploy. SQL migration files are dense — a 200-line ALTER TABLE script can hide a single destructive change in plain sight. Before you run psql or flyway migrate, you should know exactly what changed between the last version and the new one.

When You Need to Diff SQL Queries

SQL diffs come up in more situations than just migrations:

• Migration review— a teammate opens a PR with a new migration file. The filename changed but you want to see what actually changed in the SQL versus the previous version of that table's schema.
• Environment drift — your staging database schema has diverged from production. Dump both schemas with pg_dump --schema-onlyand diff them to find what's out of sync.
• Query optimization — you rewrote a slow query and want to verify the logic is equivalent. A side-by-side diff makes it easy to confirm that only the JOIN order or index hint changed, not the filtering conditions.
• ORM-generated SQL — ORMs like SQLAlchemy, Prisma, and ActiveRecord generate migration SQL automatically. Diff the generated SQL against the previous migration to catch unexpected column renames or type changes the ORM inferred incorrectly.
• Stored procedure changes — diffing two versions of a stored procedure or function body to understand what business logic changed.

How to Diff SQL Queries Online

1. Copy the original SQL — the current migration file, the production schema dump, or the previous version of the query from git history (git show HEAD~1:migrations/0042_users.sql).
2. Paste it into the Original pane on Online Diff.
3. Copy the new SQL — the updated migration, the staging schema dump, or the rewritten query.
4. Paste it into the Modified pane and hit Compare.

The diff engine highlights every changed line with word-level precision. Added lines are green, removed lines are red, and changed words within a line are highlighted inline — so a single changed column type stands out immediately instead of forcing you to scan both versions manually.

A Practical Example: Catching a Dropped Column

Consider two versions of a migration for a users table. The original adds a phone column; the new version quietly removes it:

-- Original migration
ALTER TABLE users
  ADD COLUMN phone VARCHAR(20),
  ADD COLUMN email_verified BOOLEAN NOT NULL DEFAULT FALSE,
  ADD COLUMN last_login_at TIMESTAMPTZ;

-- New migration (submitted in PR)
ALTER TABLE users
  ADD COLUMN email_verified BOOLEAN NOT NULL DEFAULT FALSE,
  ADD COLUMN last_login_at TIMESTAMPTZ;

Paste both into the diff tool and the removed phone line is immediately obvious in red. Without a diff, this is easy to miss when reviewing a 50-line migration file in a GitHub PR.

Tips for Better SQL Diffs

Normalize formatting first

SQL formatters vary — one developer writes all keywords in uppercase, another in lowercase. One wraps column definitions one-per-line, another keeps them on a single line. Before diffing, run both files through the same formatter so the diff reflects logic changes, not style differences. Tools like pg_format or online SQL formatters can normalize both files. Then paste the normalized output into the diff tool.

Diff schema dumps for environment comparison

To compare two live databases, dump just the schema without data:

# PostgreSQL
pg_dump --schema-only --no-owner -h prod-host -U user mydb > prod_schema.sql
pg_dump --schema-only --no-owner -h staging-host -U user mydb > staging_schema.sql

Paste both dump outputs into the diff tool. You'll see every table, index, constraint, and sequence that differs between the two environments — all in one view.

Use word-level diff for long single-line statements

Some SQL statements — particularly CREATE INDEX or CHECK constraints — are written as a single long line. Switch to Word diff mode in the toolbar to highlight exactly which part of the line changed, rather than showing the entire line as modified.

Diff individual statements when the file is large

For large schema dumps with hundreds of tables, extract just the table or function you care about before pasting. This keeps the diff focused and fast:

# Extract a single table definition from a pg_dump
sed -n '/^CREATE TABLE public.users/,/^;/p' prod_schema.sql

Privacy: Your SQL Stays in Your Browser

SQL migration files and schema dumps frequently contain table names, column names, and constraint definitions that reflect your internal data model. Schema structure is sensitive — it reveals what data you collect and how it's organized. Online Diff runs the entire comparison in JavaScript in your browser tab. Nothing is sent to a server, nothing is logged, and nothing is stored. Close the tab and the SQL is gone.

Related Guides

• How to Diff Terraform tfvars Files — catch config drift between environments before a destructive apply
• How to Compare Two API Responses Online — diff JSON payloads to catch schema changes in API contracts
• How to Diff Docker Compose Files Before Deploying — review infrastructure changes before they go live