RunLocalTools

SQL Schema Diff Checker — Compare CREATE TABLE Dumps Free

Paste two SQL schema dumps and see exactly which tables, columns, and keys changed — plus auto-generated ALTER TABLE migration SQL for MySQL, PostgreSQL, SQL Server, and SQLite. Runs entirely in your browser.

What it does

Paste or drop two SQL exports — a “before” and an “after” — and this tool compares their structure table by table: which tables were added or removed, which columns changed type, nullability, or default value, and which primary keys, foreign keys, and unique constraints changed. It works across MySQL, PostgreSQL, SQL Server, and SQLite dumps, and it can generate ready-to-review migration SQL to take you from the old schema to the new one.

How it works

The parser reads CREATE TABLE statements directly — it doesn’t require a live database connection or a specific dialect. It recognizes backtick-quoted identifiers (MySQL), double-quoted identifiers (PostgreSQL/SQLite), and bracket-quoted identifiers (SQL Server), and it tolerates comments, ENGINE=/DEFAULT CHARSET trailing clauses, IF NOT EXISTS, and multiple tables in one dump. Each table’s columns, primary key, foreign keys, and unique constraints are extracted into a structural model, and the two models are diffed field by field rather than compared as text — so reordering columns or reformatting whitespace between the two files won’t produce false differences.

The migration SQL generator walks that same diff and emits the corresponding ALTER TABLE statements for whichever dialect you pick. It’s dialect-aware about real differences — for example PostgreSQL splits a column change into separate ALTER COLUMN … TYPE and SET/DROP NOT NULL statements, SQL Server requires the full column definition to be restated, and SQLite has no ALTER COLUMN at all, so those changes are flagged as needing a table rebuild rather than silently generating invalid SQL.

How to use it

  1. Paste or drop your “before” schema into the left box, and your “after” schema into the right.
  2. Review the summary chips and the per-table breakdown — additions, removals, and modifications are color-coded.
  3. Pick a target SQL dialect in the sidebar and click “Generate migration SQL” for ready-to-review ALTER TABLE statements.
  4. Export the diff report itself as Markdown, plain text, or JSON if you need to share or archive it.

A note on the generated migration SQL

This is a structural diff, not a live database introspection tool, so the generated SQL is a strong starting draft rather than something to run blind. In particular: SQL Server’s ALTER COLUMN needs its full type and nullability restated (the tool does this, but double-check it against your actual current definition), dropping a named constraint needs the constraint’s real name if your dump didn’t specify one, and SQLite can’t alter a column in place at all — those cases are called out as comments in the output rather than generated as executable statements. Always review generated migration SQL against a copy of your database before running it against production.

FAQ

Does this connect to my actual database? No — it only reads the SQL text you paste or upload (a schema dump, or CREATE TABLE statements you export yourself). Nothing is sent anywhere or executed.

Can I compare schemas from different database engines? Yes — the parser is dialect-tolerant, so you could technically diff a MySQL dump against a PostgreSQL one, though the most common use is comparing two versions of the same schema over time (e.g. before and after a migration, or your local schema against staging).

Why does the migration SQL have comments instead of statements for some changes? A few operations aren’t safely auto-generatable: SQLite has no ALTER COLUMN/DROP PRIMARY KEY, and an unnamed constraint can’t be dropped by name. Those are called out explicitly in the output rather than guessed at.

My schema didn’t parse — what happened? The tool needs standard CREATE TABLE name ( ... ); syntax. If a table doesn’t appear, check for unbalanced parentheses or a non-standard extension your database added; any lines it couldn’t parse are listed as warnings above the diff.

Can I ignore formatting differences like comments or casing? Yes — toggle “Ignore SQL comments” to strip -- and /* */ comments before parsing, and “Ignore case in type names” to treat varchar and VARCHAR as identical.

Does it detect renamed columns or tables? No — a rename shows up as one column/table removed and a different one added, since there’s no reliable way to distinguish a rename from a genuine drop-and-add from structure alone. Rename detection would need extra metadata this tool doesn’t have access to.

If you’re documenting the resulting schema rather than migrating it, the SQL → Markdown table generator turns the same CREATE TABLE dumps into clean README-ready tables, and the SQL → ER diagram tool visualizes the relationships between tables. For formatting a messy dump before diffing it, the SQL formatter can clean up indentation and casing first.