Forward-only migrations
Forward-only migrations can only move the schema forward; mistakes are fixed by adding new migrations, not by reverting old ones.
How it works
- Apply
V5 - Something’s wrong → create
V6to fix or compensate - History is immutable
Why teams use this
- Safe with live traffic
- Works with rolling deployments
- No data loss from “undoing” changes
- Simple mental model
Typical tools / usage
- Flyway (default, recommended)
- Liquibase (common practice in prod)
Production reality
This is the industry standard.
Reversible migrations
Reversible migrations define both how to apply a change and how to undo it.
How it works
- Apply change
- Tool knows (or you define) how to reverse it
- Rollback is an explicit action
Why teams like the idea
- Fast recovery in dev/test
- Auditable change control
- Required in some regulated environments
Why it’s dangerous in prod
- Data may already be written
- Old app versions may still run
- Rollback can silently destroy business state
Typical tools
- Liquibase (explicit rollbacks)
- Flyway undo migrations (limited)
Side-by-side
| Aspect | Forward-only | Reversible |
|---|---|---|
| Prod safety | ✅ High | ❌ Risky |
| Data safety | ✅ Preserved | ❌ Can lose data |
| Rolling deploys | ✅ Works | ❌ Breaks |
| Complexity | Low | High |
| Used in prod | ✅ Yes | ⚠️ Rare |
One-sentence interview answer (memorize this)
Forward-only migrations fix problems by applying new compensating changes, while reversible migrations attempt to undo past changes, which is convenient in controlled environments but unsafe in production once data and traffic are involved.
Senior rule of thumb
Schemas can move forward safely; data almost never moves backward safely.