Flyway vs Liquibase — Decision Criteria and Baseline Strategy
Fast recall
Quick revision
Core answer
V2__ for new changes. Never let Flyway run the baseline against an existing schema — it would attempt to recreate tables that already exist. The decision is technical fit + team workflow: SQL-first teams pick Flyway, abstraction-first teams or polyglot DB shops pick Liquibase.Ability to compare Flyway and Liquibase across real production criteria, and to introduce migrations safely into an existing legacy database
Treating it as 'Flyway is simpler so always Flyway' without considering rollback, multi-DB, or DBA workflow needs; or running Flyway against a legacy DB without baselining
Discuss preconditions, contexts/labels, rollback semantics, baseline workflows, and how migration tools fit into CI/CD and database CI
Interview-ready guide
Interview answer
Both tools manage versioned schema migrations, but they have different philosophies.
Flyway:
- SQL files with strict naming —
V1__create_orders.sql - Simple, low-ceremony, fast onboarding
- Default choice for new Spring Boot services
- Excellent Postgres/MySQL support — write native SQL directly
Liquibase:
- Abstract changesets in XML, YAML, JSON, or SQL
- Same changelog targets multiple databases
- Built-in rollback for many change types
- Preconditions, contexts, labels for conditional execution
- Wins in DBA-driven workflows and multi-DB shops
Decision rule:
- Single DB, SQL-first team -> Flyway
- Multi-DB, DBA approvals, rollback requirements -> Liquibase
- Default in 2026 — Flyway
Baselining a legacy database:
- Dump current schema as
V1__baseline.sql - Set
baseline-on-migrate=trueandbaseline-version=1 - Flyway marks V1 as applied without running it
- New changes start from V2
- Always pair with
ddl-auto=validateto confirm entities match the live schema
Common pitfalls:
- Editing applied migrations — both tools refuse on checksum mismatch
- Mixing both tools on one DB — pick one
- Big-table DDL during business hours — use online schema change tools
Flyway vs Liquibase — Decision Criteria and Baseline Strategy
Direct Answer
Flyway is the default for new Spring Boot projects — SQL-first, simple, low ceremony, excellent Postgres/MySQL support. Liquibase wins when you need automatic rollback, multi-database portability from one changelog, conditional changes (preconditions), or strong support for DBA-driven approval workflows. For an existing legacy database, baseline strategy is critical: dump the current schema as V1__baseline.sql (or a Liquibase changelog), set baseline-on-migrate=true with baseline-version=1, and start adding V2__ for new changes. Never let Flyway run the baseline against an existing schema — it would attempt to recreate tables that already exist. The decision is technical fit + team workflow: SQL-first teams pick Flyway, abstraction-first teams or polyglot DB shops pick Liquibase.
Common Mistakes & Pitfalls
Treating it as 'Flyway is simpler so always Flyway' without considering rollback, multi-DB, or DBA workflow needs; or running Flyway against a legacy DB without baselining
Check your understanding
Answer these without looking back at the article.
- How do Liquibase preconditions help you write idempotent migrations?
- What's the right way to baseline an existing legacy Postgres database into Flyway?
- When would you choose to write rollback scripts vs design forward-only migrations?
- How do migrations interact with multiple application instances during a rolling deploy?
Related interview prep categories
2Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.