Paste your old and new CREATE TABLE schemas. Instantly see every column and index change, and get a ready-to-run ALTER TABLE migration script.
Old Schema (before)
The current / existing schema
New Schema (after)
The target / updated schema
VARCHAR(20)
VARCHAR(500)
DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
-- Migration script (generated by SQL Boy Schema Diff) -- Review carefully before executing in production. -- Modified table: users ALTER TABLE `users` ADD COLUMN `phone` VARCHAR(20), ADD COLUMN `avatar_url` VARCHAR(500), ADD COLUMN `updated_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, ADD INDEX `idx_username` (`username`);
Three deterministic steps — no AI, no server, no guesswork.
01
Parse
Each schema is split into CREATE TABLE blocks. Each block is parsed into a list of columns (name + full type string) and constraints (PRIMARY KEY, UNIQUE KEY, INDEX, FULLTEXT). No external SQL engine is used — parsing runs entirely in the browser.
CREATE TABLE users ( id INT NOT NULL AUTO_INCREMENT, name VARCHAR(100) NOT NULL, PRIMARY KEY (id) ); → Table: "users" Columns: id · name Indexes: PRIMARY KEY (id)
02
Diff
Tables are matched by name (case-insensitive). Within each matched table, columns are paired by name — new columns → ADD, missing columns → DROP, same name but different type string → MODIFY. Indexes are compared as a compound key of type + name + columns.
-- Same name, different type string → MODIFY Old: name VARCHAR(100) NOT NULL New: name VARCHAR(200) NOT NULL -- In NEW only → ADD New: email VARCHAR(255) -- In OLD only → DROP Old: legacy_flag TINYINT
03
Generate
Each detected change is emitted as an ALTER TABLE clause. New tables become a full CREATE TABLE statement; dropped tables become DROP TABLE IF EXISTS. All clauses are joined into one copy-pasteable migration script with inline comments.
ALTER TABLE `users` MODIFY COLUMN `name` VARCHAR(200) NOT NULL, ADD COLUMN `email` VARCHAR(255), DROP COLUMN `legacy_flag`;
Every change type the tool can detect and the SQL it generates.
Add column
Column present in NEW schema only
ALTER TABLE `t` ADD COLUMN `col` VARCHAR(255);
Drop column
Column present in OLD schema only
ALTER TABLE `t` DROP COLUMN `col`;
Modify column
Same column name, different type/NULL/DEFAULT
ALTER TABLE `t` MODIFY COLUMN `col` BIGINT NOT NULL;
Add index
Index key in NEW schema only
ALTER TABLE `t` ADD INDEX `idx_col` (`col`);
Drop index
Index key in OLD schema only
ALTER TABLE `t` DROP INDEX `idx_col`;
New table
Table present in NEW schema only
CREATE TABLE `new_table` ( ... );
Drop table
Table present in OLD schema only
DROP TABLE IF EXISTS `old_table`;
Schema migrations are irreversible. Keep this checklist handy.
Back up first
Take a full snapshot or logical dump before running any DDL in production. Schema migrations cannot be rolled back with a simple ROLLBACK.
Test on staging with real data volume
Run the migration on a staging copy that matches production row counts. A migration that takes 1 s on a dev database may lock a 50 M-row table for minutes.
Adding a nullable column is usually fast
MySQL 8+ and PostgreSQL 11+ can add a nullable column without a default as a metadata-only operation — no table rebuild necessary.
MODIFY COLUMN may rebuild the whole table
Changing a column's data type, length, or NULL constraint triggers a full table copy in MySQL. Use pt-online-schema-change or gh-ost for large tables to avoid downtime.
DROP COLUMN is permanent
Once executed you cannot undo a column drop. Confirm that no application code, ORM model, or report still references the column before running the script.
The diff output is most useful when it sits between design review and execution. Treat it as a fast structural checkpoint, not as permission to run DDL blindly.
Use this path when you have two CREATE TABLE versions and want a fast, explicit summary before approving a migration.
Useful when a schema change is real but you still need to decide whether it is operationally safe.
A diff can mean many things: a model redesign, a relationship or constraint change, or a boundary shift around JSON and sensitive fields. These paths help route the review correctly.
Use this route when a migration review is exposing deeper schema-design questions rather than a simple column add or drop.
Relevant when the migration is changing foreign keys, uniqueness, or access patterns that may affect both correctness and performance.
Choose this route when schema evolution is moving JSON fields, sensitive columns, or integration payloads into a new structure.
If the tool shows a change you are not comfortable shipping, use these guides to understand the data-model and index implications before you write a migration plan.
Good foundation if you are still deciding what the target table structure should look like.
Helpful when a diff is really signaling duplicated facts or a table that should be split before migrating it.
Useful when the migration changes JSON columns or when semi-structured fields should become more explicit over time.
Helpful when the diff includes PRIMARY KEY, UNIQUE, or other integrity changes.
Best follow-up when the schema diff shows index adds, drops, or rewrites.
Review before running in production
Generated ALTER TABLE statements are a starting point. Always review the migration in a staging environment first, especially for large tables where adding/modifying columns requires careful planning around locking and downtime.