DB Schema Changes in CI/CD: Flyway vs Liquibase Comparison and Implementation Guide

A Complete Guide to Managing DB Schema Changes as Code in Your CI/CD Pipeline (Flyway vs Liquibase)

"We need to change the DB schema for this new feature… who applies the change, and how do we test it?"

Have comments like that slowed your team down, or have you spent a night firefighting unexpected data mismatches right before a release? Manual database schema changes (DB migrations) are one of the most fragile, high-risk points in modern software delivery. Code is committed to Git and applications are built as container images, but the database is still often treated as a kind of magic box.

It does not have to be that way. Infrastructure as Code (IaC) is no longer limited to OS and network configuration. Managing database schemas as code—Database as Code (DBaC)—is becoming an industry standard. This article walks from the DBaC concept through real CI/CD integration with Flyway and Liquibase, with a practical guide you can apply immediately.

Why schema changes are risky—and why they belong in code

The core risks of manual database changes are inconsistency and non-repeatability.

1. Human error: A DBA mistake or a missing change script can be catastrophic in production.
2. Hard-to-track versions: It is difficult to see who changed the schema, when, and in what order.
3. Painful rollbacks: Recovering from a failure often means yet another complex manual process.

DBaC puts all of this under Git practices (version control and code review) so database changes are treated as deployable artifacts.

Core migration tools compared: Flyway vs Liquibase

The two most widely used tools for DBaC are Flyway and Liquibase. They share the same goal, but differ in mechanics and philosophy, so pick based on how your team works.

💡 Hands-on comparison: how each tool actually works

Flyway (script-centric): Flyway runs versioned SQL files in order—V1, V2, V3, and so on. The contract is explicit: “for this version, run this SQL.”

-- V1__initial_schema.sql
CREATE TABLE users (
    id BIGINT PRIMARY KEY,
    username VARCHAR(100) NOT NULL
);

-- V2__add_email_column.sql
ALTER TABLE users ADD COLUMN email VARCHAR(255);

Liquibase (changeset-centric): Liquibase prefers defining what should change (a ChangeSet) rather than writing the SQL itself.

# changesets/20240101_add_email.yaml
databaseChangeLog:
  - changeSet:
      id: add_email
      author: devops
      changes:
        - addColumn:
            tableName: users
            columnName: email
            type: varchar

Practitioner take: Many teams start with Flyway because plain SQL feels obvious. When a backend later had to support PostgreSQL and MySQL at the same time, Liquibase’s ability to abstract platform differences became the bigger advantage. Choose based on project complexity and whether you need multi-database support.

Integrating DB migrations into the CI/CD pipeline

DBaC pays off when it is wired into CI/CD—not only at deploy time, but from the test stage onward.

A typical per-stage flow looks like this.

[Build] → [Test] → [Deploy] migration flow

1. Build stage:
   • Build application code and run tests.
   • Produce a DB migration artifact: bundle every script Flyway/Liquibase manages (versioned) into the build output.
2. Test stage (most important):
   • Goal: Prove the application works against the new schema.
   • How: Spin up a temporary test database, apply the full latest set of migration scripts in order, then run tests to catch query failures.
3. Deploy stage:
   • Goal: Apply changes to the real production database.
   • How: Run the migration tool before application deploy. The tool checks the current DB version and safely runs only scripts that have not been applied yet.

🛡️ Rollback strategy when things fail

What if a migration script fails during deploy?

• Built-in Flyway/Liquibase rollback: Both tools support a rollback command, but perfect automatic rollback is very hard because of how schema changes work. If a DROP TABLE that deletes data fails partway, the data is still gone no matter how hard the tool tries.
• Recommended strategy (data backup + code rollback):
  1. Back up data: Take a production snapshot or back up critical tables immediately before migration.
  2. Roll back the application: If migration failure is detected, roll the application deploy back to the previous version.
  3. Manual recovery: If data loss is unavoidable, restore from the backup.

Checklist for stable database operations

Use this team-level checklist when adopting DBaC.

• Is every DB schema change committed to version control (Git)?
• Do development, staging, and production share the same DB schema version?
• Are transactions handled explicitly inside migration scripts?
• Do you have test cases for rollback scenarios?

With this kind of discipline, the database stops being a dangerous black box and becomes a stable, code-managed part of the service.

FAQ

Q1. Won’t a migration tool slow us down? A1. Setup and script writing take time up front, but once the pipeline exists, you lose the hours spent on manual work and rework from human error. Over time, both speed and reliability go up.

Q2. I don’t know whether to pick Flyway or Liquibase. A2. If the team is very comfortable with SQL and you mostly use one database, Flyway is fast and intuitive. If you must support several databases, or you want an abstraction layer that non-developers can follow more easily, Liquibase may be a better fit.

Q3. Should data changes (INSERT/UPDATE) be separated from schema changes (ALTER) in migration scripts? A3. Yes—separating them is the safest default. Run schema changes (DDL) first to establish structure, then run data changes (DML).

[Practitioner tip] The hardest production issue we hit was trying to wrap data changes (DML) and schema changes (DDL) in the same transaction. DDL often has fuzzy transaction boundaries and behaves differently across engines. The safest pattern we learned: run DML in a separate script after the schema change has completed.