Java.DBMigrationTools.How do you support rollbacks in Flyway (if at all)?

Why Flyway avoids rollbacks

• DDL is often non-transactional (Postgres CREATE INDEX CONCURRENTLY, MySQL online DDL, etc.).
• Data migrations are irreversible (backfills, deletes, transforms).
• Automatic rollback scripts give a false sense of safety.

Flyway chooses forward-only, auditable history over fragile reversibility.

If you say “Flyway rollback” in an interview, the follow-up is usually:

“Okay, then how do you recover safely?”

---

What Flyway actually provides

1) No automatic undo for versioned migrations

• Once a Vxxx__*.sql is applied, Flyway will never revert it.
• There is U__ (undo) support in Flyway Teams edition, but:
  • limited adoption
  • not safe for complex/data-heavy migrations
  • many teams intentionally don’t use it

2) repair ≠ rollback

• flyway repair only fixes metadata:
  • removes failed entries
  • recalculates checksums
• It does not revert schema or data.

---

How rollback is handled in real Flyway setups

Strategy 1 — Fix-forward (most common, safest)

If prod is broken:

• Write a new migration that:
  • reverts logic (e.g., re-add column, recreate index)
  • or patches data
• Deploy it immediately

Example:

V120__drop_old_flag.sql   ❌ caused issue
V121__restore_old_flag.sql ✅ fix-forward

Why interviewers like this

• Works with immutable history
• Fully auditable
• No hidden DB state changes

Strategy 2 — Expand–Migrate–Contract (zero-downtime rollback)

This is the real rollback mechanism.

Expand

• Add new nullable column / table
• Don’t remove old stuff

Deploy

• App can work with old + new schema

Migrate

• Backfill data safely

Contract

• Drop old column later

Rollback scenario

• If deploy fails → app switches back to old path
• DB schema is still compatible → no DB rollback needed

This is how you survive bad deploys without touching the DB.

Strategy 3 — DB backups & restore (last resort)

For catastrophic cases:

• Restore DB snapshot
• Reapply migrations up to known-good version
• Redeploy app

This is operational rollback, not Flyway rollback.

Important

• You must know:
  • RPO / RTO
  • how long restore takes
  • how to re-sync replicas / shards

---

Strategy 4 — Undo migrations (Teams edition, niche use)

Flyway Teams allows:

U120__drop_old_flag.sql

Reality

• Useful for:
  • simple DDL in dev/test
• Dangerous for:
  • prod
  • data migrations
  • anything non-transactional

Many senior teams explicitly forbid undo in prod.

How I’d phrase it in an interview (this matters)

“Flyway doesn’t support true rollbacks by default, and that’s intentional. In production we use forward-only migrations and rely on expand–migrate–contract so the application can roll back without reverting the database. If a migration causes issues, we fix-forward with a new migration. For disasters, rollback means restoring from backup, not undoing SQL.”

What I expect a strong candidate to mention

• ❌ “I rollback migrations” → red flag
• ✅ “I rollback the application, not the database”
• ✅ Expand–migrate–contract
• ✅ Fix-forward
• ✅ Backups as the real rollback
• ✅ Non-transactional DDL awareness