This runbook provides step-by-step procedures for rolling back database migrations safely.
- Identify the migration to rollback
- Verify backup exists and is valid
- Check current database state
- Notify stakeholders of rollback operation
- Ensure maintenance window is active
- Document reason for rollback
# Check migration history
psql -c "SELECT * FROM migration_history ORDER BY executed_at DESC LIMIT 5;"
# Verify current schema version
psql -c "\dt"./backup_database.sh# Execute rollback migration
./migrate.sh down 001_create_products.sql# Check table structure
psql -c "\dt"
# Verify data integrity by checking remaining tables
psql -c "SELECT table_name FROM information_schema.tables WHERE table_schema = 'public' ORDER BY table_name;"
# Test application connectivity
psql -c "SELECT current_database(), current_user;"# Record rollback in migration history
psql -c "SELECT * FROM migration_history ORDER BY executed_at DESC;"
# Update status notes if required
psql -c \"UPDATE migration_history
SET notes = COALESCE(notes, '') || E'\nRollback reviewed and documented.'
WHERE migration_name = '001_create_products.sql'
AND status = 'rolled_back';\"- Database schema matches expected state
- Application functions correctly
- No data loss occurred
- Performance metrics normal
- Monitoring alerts cleared
| Scenario | Action | Priority |
|---|---|---|
| Syntax error in migration | Immediate rollback | Critical |
| Performance degradation | Assess impact, rollback if severe | High |
| Data corruption | Immediate rollback + restore | Critical |
| Missing dependency | Rollback, fix, re-apply | Medium |
- Database Administrator: [Contact Info]
- DevOps Lead: [Contact Info]
- Application Owner: [Contact Info]
After each rollback, document:
- What went wrong?
- Why wasn't it caught in testing?
- What changes prevent recurrence?
- Update to migration process needed?