DevLab
{}
JSONintermediate

DB Schema Diff

compare two database schemas and spot column-level changes

By Bikram NathLast updated

The DB Schema Diff tool compares two database schemas (SQL CREATE TABLE statements) and generates the ALTER TABLE migration needed to transform one into the other. Paste your current schema and target schema as SQL DDL, and get a precise migration script showing added columns, dropped columns, modified types, new indexes, and constraint changes. All processing happens in your browser — no database connection required.

Try it now — free, instant, no signup

What is DB Schema Diff?

A database schema diff tool takes two sets of SQL Data Definition Language (DDL) statements — typically CREATE TABLE blocks — and computes the structural differences between them. Instead of manually comparing two schema dumps line by line, you get a machine-generated list of ALTER TABLE, ADD COLUMN, DROP COLUMN, and MODIFY COLUMN statements that would transform schema A into schema B.

This solves a concrete problem in every database-backed application: you have a production schema and a development schema that have diverged, and you need to write the migration that brings production up to date. Doing this by hand is error-prone — it is easy to miss a renamed column, a changed default value, or a dropped index. A schema diff tool catches every difference systematically.

The tool parses standard SQL DDL syntax and understands column types, NULL/NOT NULL constraints, DEFAULT values, PRIMARY KEY and UNIQUE constraints, foreign keys, and indexes. It works with PostgreSQL, MySQL, and SQLite DDL syntax. The output migration is ordered safely — columns are added before they are referenced in constraints, and foreign keys are dropped before the tables they reference are modified.

When to use DB Schema Diff

Generate a migration script when your ORM (Prisma, Drizzle, TypeORM) auto-generated schema has drifted from your production database and you need the exact ALTER statements.
Review schema changes in a pull request by diffing the before and after SQL dumps to ensure no accidental column drops or type changes.
Compare a vendor-provided schema update against your current database to plan a migration without reading through hundreds of lines of CREATE TABLE statements.

Expert Notes

Schema diffs show structural changes but miss behavioral ones — a column renamed from `user_id` to `account_id` appears as a drop + add, not a rename, so the diff alone can't tell you if data will be migrated or lost. Always review generated migration scripts for implicit data loss: dropping a NOT NULL constraint is safe, but adding one to a column with existing NULLs will fail at runtime. For teams, storing schema diffs in version-controlled migration files (Flyway, Liquibase, Alembic) is safer than applying manual DDL — the diff tool helps you verify what changed, the migration file is the authoritative source of truth.

DevLab's Take

Most useful during code review of database migrations or when syncing a staging schema back to dev — in production workflows, you need proper migration tooling, not a browser diff tool.

Frequently Asked Questions

What SQL dialects does it support?
The parser handles PostgreSQL, MySQL, and SQLite CREATE TABLE syntax including data types, constraints (PRIMARY KEY, UNIQUE, NOT NULL, DEFAULT, CHECK, FOREIGN KEY), and CREATE INDEX statements. Dialect-specific features like PostgreSQL arrays, MySQL AUTO_INCREMENT, and SQLite AUTOINCREMENT are recognized. Stored procedures, triggers, and views are not compared — only table and index definitions.
Does it generate safe migration scripts?
The output migration orders operations to avoid dependency errors: new tables are created before foreign keys referencing them, columns are added before constraints using them, and foreign keys are dropped before referenced tables are modified. However, you should always review the output and test it against a staging database before running in production — the tool does not know about your data volume or locking implications.
Can it detect column renames?
No — column renames are ambiguous in DDL comparison. If column "name" disappears and column "full_name" appears with the same type, the tool reports a DROP and an ADD rather than guessing it was a rename. This is the correct conservative behavior — an incorrect rename guess could cause data loss. Add RENAME COLUMN statements manually when needed.
How does it handle type changes?
Type changes (e.g., VARCHAR(100) to VARCHAR(255), or INTEGER to BIGINT) are reported as ALTER COLUMN modifications. The tool shows both the old and new type so you can assess whether the change is safe (widening is usually fine, narrowing can truncate data). It does not generate CAST expressions — you handle data conversion separately.
Does it need a live database connection?
No. The tool works entirely with SQL text — paste your CREATE TABLE statements from a pg_dump, mysqldump, or schema.sql file. No database credentials, no network requests, no server-side processing. Your schema DDL stays in your browser.

Related Tools