VoriTools

SQL Schema Diff and Migration Draft

Paste the old and new schemas and choose a dialect. Review the generated SQL: table and column drops are commented out, and every other statement should be checked before it runs.

Runs locally in your browser
View category: SQL & Databases (12)
This tool processes all data locally in your browser.
Schema snapshotsPaste old and new CREATE TABLE SQL.
Migration draftDestructive actions are commented for review.
Run the tool to display the locally processed result here.

How to compare two schema snapshots and draft a migration

Paste the old schema in Before and the new one in After, choose PostgreSQL or MySQL, and press Generate migration. The tool reads the CREATE TABLE statements and writes the ALTER and CREATE statements that move one snapshot to the other.

Everything runs in the browser; no schema text leaves the page. The result is a review draft: statements that can destroy data are written as comments so nothing is executed by accident.

  1. Paste the current schema into Before, or take it from a schema-only dump (pg_dump --schema-only or mysqldump --no-data).
  2. Paste the target schema into After, or run that dump again after the change you want to apply.
  3. Pick the dialect of the server that will run the migration, then press Generate migration.
  4. Read the findings list first: additions, changes and destructive items are listed separately, and the destructive statements stay commented in the draft.
  5. Copy or download schema-migration.sql, run it on a staging copy inside a transaction where the engine supports it, and only then apply it to production.

What the draft covers, what it leaves commented, and what it skips

What the draft detects

It compares tables and columns: added and removed tables, added and removed columns, type changes, NOT NULL changes and DEFAULT changes. PRIMARY KEY additions, removals and column-set changes are reported too, including table-level PRIMARY KEY (a, b) definitions.

FOREIGN KEY definitions are compared whether they are written on the column (REFERENCES users(id)) or as a table-level constraint (FOREIGN KEY (a, b) REFERENCES parent (x, y)). A new key becomes ADD CONSTRAINT, and a dropped one is commented for review under the constraint name the tool would use.

What stays commented, and what is skipped

DROP TABLE, DROP COLUMN and dropped primary or foreign keys are printed as comments under a DESTRUCTIVE marker, because they discard data or constraints that re-running the tool cannot bring back. This page never executes the draft; you decide which lines to enable.

Only CREATE TABLE statements are read. UNIQUE, CHECK and INDEX definitions are not compared, and data changes, renames, views, sequences, triggers, grants and vendor-specific table options are outside the scope. When those definitions were skipped, the draft says so instead of reporting a clean diff.

Running the draft safely

Test on a staging copy first and generate the schema with a schema-only dump so that data does not hide the diff. PostgreSQL runs most DDL inside a transaction, so BEGIN and ROLLBACK can undo a wrong migration; MySQL commits DDL implicitly, so a mistake there has to be repaired forward.

Adding NOT NULL or a primary key validates or rewrites an existing table and can hold a lock while it does. Check how long that takes on the real table size (PostgreSQL validates NOT NULL with a full scan, MySQL may rebuild the table) and schedule the change instead of running it at peak traffic.

Recent tools: