Flyway vs Liquibase: A Developer’s Guide to PostgreSQL Database Migrations (Without Breaking Your Database or Your Budget)

The Quick Pitch

Flyway: Write SQL files, name them V1__description.sql, drop them in a folder. Done. It's so simple that if you can write SQL, you're already productive.​

Liquibase: More powerful but needs setup. XML, YAML, JSON, or SQL changelogs. Gives you preconditions, rollbacks, and enterprise features. Think of it as the Swiss Army knife — powerful if you need it, overkill if you don’t.​

Why This Matters

Without a migration tool, your team manually applies SQL scripts to each environment. Dev A changes the schema locally, Dev B doesn’t know about it, production breaks. Migration tools version your database changes like Git versions your code.​

Setup: Let’s Be Real

Flyway with PostgreSQL + Spring Boot

<dependency>
    <groupId>org.flywaydb</groupId>
    <artifactId>flyway-core</artifactId>
</dependency>

spring.datasource.url=jdbc:postgresql://localhost:5432/yourdb
spring.datasource.username=postgres
spring.datasource.password=password

Create file: src/main/resources/db/migration/V1__create_users_table.sql

CREATE TABLE users (
    id UUID PRIMARY KEY,
    email VARCHAR(255) NOT NULL,
    name VARCHAR(255),
    created_at TIMESTAMP DEFAULT NOW()
);

Start your app. Flyway runs the migration. That’s it.​

Liquibase with PostgreSQL + Spring Boot

Same dependency, same database config. But create a changelog:

<databaseChangeLog xmlns="http://www.liquibase.org/xml/ns/dbchangelog">
    <changeSet id="1" author="developer">
        <createTable tableName="users">
            <column name="id" type="uuid">
                <constraints primaryKey="true"/>
            </column>
            <column name="email" type="varchar(255)">
                <constraints nullable="false"/>
            </column>
            <column name="name" type="varchar(255)"/>
        </createTable>
    </changeSet>
</databaseChangeLog>

Slightly more setup, but equally reliable.​

The Cost Reality

Flyway

• Free: Community edition — perfect for small teams​
• $620/user/year: Teams edition — adds rollback support​
• Custom (expensive): Enterprise — starts around $140K+​

Liquibase

• Free: Community edition — includes basic rollbacks​
• $33–249/month/user: Paid tiers — add targeted rollbacks, drift detection, policy checks​

Real talk: Both free versions work great. Liquibase’s free tier has better rollback support, which matters during development. Once you scale, Liquibase tends to be cheaper for teams while Flyway’s per-user model gets expensive fast.​

The Dealbreaker: Rollbacks

Flyway’s free tier doesn’t have rollbacks. You write manual undo scripts or pay up.​

Liquibase’s free tier has basic rollbacks. They work for development.​

If you’re iterating rapidly locally, this matters. In production, both approaches assume you don’t rollback much (follow the expand-contract pattern instead).​

Feature Comparison

Developer Experience

I’ve used both extensively. Here’s the honest truth:

Flyway wins on: Speed, simplicity, getting started immediately. Your junior devs will be productive in an hour.​

Liquibase wins on: Flexibility, scaling to complex workflows, handling multiple databases, and rollback capability without paying.​

For solo projects and startups? Flyway.​

For enterprise teams and regulated industries? Liquibase.​

PostgreSQL-Specific Tips

Both tools handle PostgreSQL beautifully because PostgreSQL supports transactional DDL — if a migration fails, the whole transaction rolls back.​

One critical thing: test migrations on production-sized data locally. A migration that takes 10ms on 1,000 rows might take 10 minutes on 10 million rows and lock your table in production.​

Use PostgreSQL’s EXPLAIN ANALYZE to test migration performance before going live.​

When Developers Own Database Migrations

Modern teams have developers handling migrations instead of hiring DBAs. It’s efficient but requires discipline:​

✅ Do this:

• Keep migrations small and focused​
• Test thoroughly on production-like data​
• Use the expand-contract pattern (never mix add with drop)​
• Have a rollback plan, even if manual​
• Review migrations in pull requests like code​

❌ Don’t do this:

• Assume a migration works on production just because it worked locally​
• Create indexes without understanding their impact​
• Drop columns without backups​
• Skip staging environment​

My Take

Start with Flyway. It’s so simple you’ll be productive immediately. If you hit limitations (multiple databases, need free rollbacks, need enterprise features), migrate to Liquibase.​

Most teams never need to migrate. Flyway’s simplicity is often the right choice.​

One Final Thing

The tool doesn’t matter as much as your process. Treat database changes like code: version them, test them, review them in pull requests, and keep them small.​

Whatever you choose, your database will thank you. And so will your sleep schedule