Flyway versioned undo scripts vs. repeatable migrations for zero-downtime rollback

Rollback strategy for zero-downtime deployments

Our team uses Flyway 10.x with PostgreSQL 15 in a blue-green deployment pipeline. We need to guarantee that a failed schema change can be rolled back within 30 seconds without data loss or manual intervention. The current baseline uses versioned migrations (V1__..., V2__...) with manually written undo scripts (U2__...).

Trade-off

Versioned undo scripts provide explicit control but require maintaining inverse DML/DDL for every change, increasing review burden and drift risk. Repeatable migrations (R__...) auto-reapply on checksum change but offer no built-in rollback mechanism—Flyway simply re-executes them forward, which is unsafe for destructive changes like column drops.

The constraint is a hard rollback SLA: the database must return to a known-good state automatically after a failed health check, without operator decisions.

• Can repeatable migrations be made rollback-safe for additive-only changes (indexes, views) while keeping versioned undo scripts for destructive changes?
• Does Flyway's undo command in 10.x support conditional execution based on migration type, or must we gate rollback logic in a wrapper script?
• Are there documented patterns for mixing both migration types in a single pipeline while preserving a single rollback entry point?