# Migration SQL Diff

> Generate a migration SQL diff with Schemity - compare your edited ERD against the live database to produce the ALTER statements that evolve your schema, then apply them.

Source: https://schemity.com/doc/migration-sql-diff/

Schemity's **ERD migration SQL diff** compares your edited diagram against the connected database and produces the SQL that brings the database in line with your design. Creating a schema from scratch is the easy case; the harder, more common case is changing a schema that already has data, and that is the case the diff handles. This is a licensed desktop feature.

## What is a migration SQL diff?

Full DDL re-creates everything. A migration diff instead emits only the **changes** - the `ALTER TABLE`, `ALTER COLUMN`, `CREATE`, and `DROP` statements needed to move the live database from its current shape to your edited diagram. Schemity tracks original names during introspection, so renames are detected rather than emitted as drop-and-create.

## How do I generate and apply a migration?

1. Connect to the database and reverse-engineer it (see [Reverse-Engineer an Existing Database](https://schemity.com/doc/reverse-engineer-database/)).
2. Edit the model - add an entity, add a field, tighten a constraint.
3. Generate the migration; Schemity shows the SQL it will run, the database it targets, and the [impact findings](https://schemity.com/doc/impact-analysis/) - data loss, statements that can fail on existing rows, table rewrites, and dependent objects.
4. Review it, then choose **Apply SQL statement** in the **Migration confirm** dialog to run it against the database. On a connection with **Ask for the database name before applying a migration** turned on - the default for Production - type the database name first.

The diff is emitted in your engine's syntax, so the statements are ready to run.

Until a migration is applied, anything that exists only in the diagram - a new entity you sketched or pasted - wears a dashed border, and the diagram's JSON keeps the last database-confirmed state. Apply the migration and the drafts become solid, saved schema - see [Keep Your ERD in Sync with the Database](https://schemity.com/doc/resync-database/).

Before you generate a migration is a good moment to run [Schema Lint](https://schemity.com/doc/schema-lint/) over the diagram: a foreign key whose type does not match the column it references, or a default the column's own check constraint forbids, is cheaper to find on the canvas than in the output of a failed `ALTER`.

## How does each database engine apply the migration?

Schemity reflects how each database handles DDL:

- **PostgreSQL and SQL Server** run the migration in a transaction, rolling back if a statement fails.
- **MySQL** commits each DDL statement immediately, so if one fails, earlier ones remain applied. Review MySQL migrations especially carefully.

## Why should I review the migration before running it?

A generated migration is a strong starting point, not a blind command. Destructive operations - dropping a column, narrowing a type - deserve a careful read and a backup before they touch production data. [Impact Analysis](https://schemity.com/doc/impact-analysis/) puts numbers on that read: how many rows a dropped column holds, how many nulls block a `SET NOT NULL`, and which views stop compiling.

[Virtual relations](https://schemity.com/doc/virtual-relations/) never appear in a migration: they document dependencies the database does not declare, so no foreign key is ever generated for them.

## You have come full circle

You can now create a workspace, connect or reverse-engineer a database, design and organize an ERD with entities and context views, version it in Git, and ship changes as SQL - all in **database design software with no cloud**. Head back to [Docs Home](https://schemity.com/doc/) any time.