Creating a schema from scratch is the easy case. The harder, more common case is changing a schema that already has data. Schemity’s ERD migration SQL diff compares your diagram against the connected database and produces the SQL that brings the database in line with your design. This is a licensed desktop feature.
What a migration diff does
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.
Generating and applying
- 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.
Know how your engine applies it
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.
Always review before running
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.