SQL Schema Diff

Processed Client Side

Compare two database table schemas, see every column that was added, removed, or changed, and generate the ALTER statements to sync either side.

Schema A (left) · Schema B (right)

CREATE TABLE users (
  id INT PRIMARY KEY AUTO_INCREMENT,
  username VARCHAR(50) NOT NULL,
  email VARCHAR(255) NOT NULL,
  full_name VARCHAR(120),
  created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
  UNIQUE KEY uq_email (email)
);

Schema A · CREATE TABLELength: 239Lines: 8Size: 239 BytesCursor: 1:1

CREATE TABLE users (
  id INT PRIMARY KEY AUTO_INCREMENT,
  username VARCHAR(64) NOT NULL,
  email VARCHAR(255),
  phone VARCHAR(20),
  created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
  updated_at TIMESTAMP,
  KEY idx_username (username)
);

Schema B · CREATE TABLELength: 249Lines: 9Size: 249 BytesCursor: 1:1

Differences

+1 only in A+2 only in B~2 changed2 constraint

Only in Schema A (left)

+ full_name VARCHAR(120)

Only in Schema B (right)

− phone VARCHAR(20)

− updated_at TIMESTAMP

Changed columns

~ username

type: varchar(50) → varchar(64)

~ email

nullability: NOT NULL → NULL

Constraints / indexes only in Schema A (left)

+ UNIQUE KEY UNIQUE KEY uq_email (email)

Constraints / indexes only in Schema B (right)

− KEY KEY idx_username (username)

Sync SQL

-- Sync Schema B (right) → match Schema A (left)
ALTER TABLE `users` ADD COLUMN `full_name` VARCHAR(120);
ALTER TABLE `users` MODIFY COLUMN `username` VARCHAR(50) NOT NULL;
ALTER TABLE `users` MODIFY COLUMN `email` VARCHAR(255) NOT NULL;
ALTER TABLE `users` DROP COLUMN `phone`;
ALTER TABLE `users` DROP COLUMN `updated_at`;
ALTER TABLE `users` ADD UNIQUE KEY uq_email (email);
-- - remove KEY (review — name/dialect specific): KEY idx_username (username)

Bookmark this tool now — skip the search next time you need it.

About SQL Schema Diff

This tool runs entirely in your browser. Whatever you paste is processed on your own device and is never uploaded, logged, or sent to any server.

The SQL Schema Diff compares two CREATE TABLE definitions and tells you exactly how they differ — which columns exist on only one side, which changed type, nullability, or default, and which constraints and indexes are missing from either. It then writes the ALTER statements that bring one schema in line with the other, in the dialect you choose. It is for the moment when staging and production have quietly drifted apart, or when a migration file needs writing and reading two CREATE TABLE statements side by side is not a reliable way to spot a changed VARCHAR length.

Key features

Column-level diff reporting additions, removals, and changes to type, nullability, default, and primary key
Constraint and index diffing, covering PRIMARY KEY, FOREIGN KEY, UNIQUE, CHECK, and plain indexes
Generated ALTER statements for MySQL, PostgreSQL, SQLite, Oracle, SQL Server, or a generic dialect
Correct per-dialect syntax: MySQL MODIFY COLUMN, PostgreSQL ALTER COLUMN … TYPE with separate SET NOT NULL and DEFAULT statements, Oracle MODIFY, and SQL Server ALTER COLUMN
Identifier quoting per dialect — backticks for MySQL, double quotes for PostgreSQL and SQLite, brackets where appropriate
A direction switch, so you can generate the migration to make either side match the other
SQLite’s ALTER limitations flagged explicitly, with a note that the table needs rebuilding rather than a statement that will not run
Tolerant parsing: quoted identifiers, comments, precision and length modifiers, UNSIGNED, AUTO_INCREMENT, and DEFAULT expressions
Summary badges counting what is only in A, only in B, and changed — with everything computed in your browser

How to use it

Paste the first CREATE TABLE statement into Schema A.
Paste the one you are comparing it against into Schema B.
Read the diff sections: only in A, only in B, changed columns, and constraint differences.
Choose the direction — make B match A, or A match B — and select your database dialect.
Review the generated ALTER statements and copy them into a migration file.

Tips & common mistakes

Treat the generated SQL as a first draft, not a migration you run unread. It is accurate about the shape of the change and cannot know your data, your locking constraints, or your deployment order.
A DROP COLUMN is not reversible and takes the data with it. Check every drop against what is actually in the table before running it anywhere that matters.
Narrowing a column — VARCHAR(255) down to VARCHAR(64), or INT to SMALLINT — fails or truncates when existing rows do not fit. Query for oversized values first.
Adding a NOT NULL column to a populated table needs a default, or it fails outright. The safe sequence is add nullable, backfill, then add the constraint.
SQLite genuinely cannot alter a column’s type or constraints. The rebuild note is the real answer there: create a new table, copy the rows across, drop the old one, and rename.
On a large MySQL or PostgreSQL table, an ALTER can lock or rewrite the whole thing. Check what your version does for the specific change before running it in production.
Diff the schema you actually deployed, not the one in your migrations folder. The point of this tool is finding the drift between what you think is there and what is.
For plain text or code rather than SQL schemas, use the general-purpose Compare Files / Diff Checker.

Browse all 3 Database tools

Frequently asked questions

Paste a CREATE TABLE statement into each pane. The diff lists columns only in A, only in B, and those that changed, along with constraint and index differences.

The generated migration can be emitted for MySQL, PostgreSQL, SQLite, Oracle, SQL Server, or a generic dialect, each using its own ALTER syntax and identifier quoting.

It decides which schema is the target. One direction generates the statements to make B match A; the other makes A match B. The diff itself is the same either way.

Review it first. It is accurate about the shape of the change but knows nothing about your data volume, locking behaviour, or deployment order — treat it as a first draft of a migration.

Because SQLite cannot alter a column’s type or constraints. The supported approach is to create a new table, copy the rows across, drop the original, and rename — which is what the note describes.

A difference in type, nullability, default value, or primary-key membership. Each change is listed with both definitions so you can see exactly what moved.

Yes. Table-level PRIMARY KEY, FOREIGN KEY, UNIQUE, CHECK, and index definitions are parsed and compared, with differences reported separately from column changes.

Because existing rows have no value for it. Add the column as nullable, backfill the data, then apply the NOT NULL constraint — or supply a default in the same statement.

Only if the data fits. Reducing VARCHAR(255) to VARCHAR(64), or INT to SMALLINT, will fail or truncate when rows exceed the new limit, so query for oversized values first.

No. Parsing, diffing, and SQL generation all run in your browser, so internal table definitions never leave your machine.

About SQL Schema Diff

Key features

How to use it

Tips & common mistakes

Related tools

Frequently asked questions