Versions and Migrations

Versioning is one of the core DBModeler workflows. A version captures the schema at a checkpoint, lets you compare changes, and generates SQL for migrations.

How versioning works

Each version stores a snapshot of the diagram plus the information needed to compute the change from the previous version.

In practice, that gives you:

• a stable checkpoint
• diff-oriented migration SQL
• rollback targets
• a place to attach version-scoped custom SQL scripts

Create a version

When your work-in-progress reaches a stable point, create a new version and add a short description.

That version becomes the baseline for later migration generation.

Review WIP versus finalized versions

DBModeler distinguishes between:

• the current working state of the diagram
• the most recent finalized version

This lets you preview what migration SQL would look like before turning those changes into a committed version.

Generate migration SQL

Version SQL is based on the diff between snapshots.

• Version 1 typically emits full schema creation SQL.
• Later versions emit migration-oriented ALTER statements and related DDL.

DBModeler applies engine rules while doing this, so the same conceptual change may export differently by engine.

Roll back to an earlier version

Use rollback when you want to restore the diagram to an earlier known-good state.

The version history is linear, not branch-based, so rollback is a deliberate history operation rather than a lightweight view switch.

Pair versions with scripts and Git

Versions work especially well when combined with:

• Custom SQL Scripts
• GitHub or GitLab migration push workflows

This gives each release point a clear schema delta and optional extra SQL around it.

Recommended workflow

1. model and review the change in WIP
2. preview export SQL
3. create the new version with a clear description
4. add custom scripts if needed
5. push or export the resulting migration SQL

Next: Custom SQL Scripts