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?
- Connect to the database and reverse-engineer it (see Reverse-Engineer an Existing Database).
- Edit the model - add an entity, add a field, tighten a constraint.
- Generate the migration; Schemity shows the SQL it will run.
- Review it, then choose Apply SQL statement in the Migration confirm dialog to run it against the database.
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.
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.
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 a local ERD tool with no cloud. Head back to Docs Home any time.