Nice one 👍 resetting migrations means “wipe the DB back to empty and re-apply everything from scratch.” How you do it depends on whether you’re in dev/test or prod.
🔹 Flyway
- Clean (drops everything)
flyway clean
Drops all objects (tables, views, etc.) in the configured schemas.
⚠️ Dangerous — should be disabled in prod by default (spring.flyway.clean-disabled=true).
Migrate again
flyway migrate
Recreates schema from your V1__... → Vn__....
Repair (optional)
flyway repair
Fixes checksums and history table after you’ve rebuilt.
🔹 Liquibase
- Drop all objects
liquibase dropAll
Clears the schema (tables, indexes, views, etc.).
Update again
liquibase update
Replays your changelogs from scratch.
Clear history (optional)
liquibase clearCheckSums
🔹 Manual “reset” (works for both)
- Drop the schema or database manually:
DROP SCHEMA public CASCADE;
CREATE SCHEMA public;
Then re-run migrations.
🔹 Best Practices
- Dev/Test: Safe to reset often (helps when experimenting). Automate via
clean+migrateor Testcontainers. - Prod: 🚨 Never reset! Instead use expand/contract and versioned migrations only. If schema drift is bad, do a dump → rebuild → restore data with a migration plan.
- Seed data: Keep test/demo data in separate scripts so you can reload after reset.