Database Schema Migration with Liquibase

Liquibase is an open-source database schema change management tool that tracks, versions, and deploys database changes. Like Flyway, it solves the problem of manual, untracked schema changes across environments. Unlike Flyway which uses plain SQL files, Liquibase introduces the concept of a changelog file that describes database changes in XML, YAML, JSON, or SQL format. Each change is encapsulated in a changeset, which is the unit of work that Liquibase tracks and applies.

The core difference between Liquibase and Flyway is that Liquibase uses database-agnostic changesets that can generate the correct SQL for different database engines (MySQL, PostgreSQL, Oracle, SQL Server) from the same changelog. This is valuable in enterprise environments where different environments run different databases. Liquibase also has stronger rollback capabilities - each changeset can define an explicit rollback operation, enabling automated rollback in CI/CD pipelines. Liquibase maintains its history in a table called DATABASECHANGELOG.

The below example shows a complete Liquibase changelog in YAML format that creates a customers table, adds an index, and then adds a new column - each as a separate versioned changeset.

It gives the following output when Liquibase runs,

Running Liquibase Community v4.25.0
Starting Liquibase at 10:00:00 (version 4.25.0)
Liquibase: Update has been successful. Rows affected: 2

Changeset db/changelog/changes/001-create-customers.yaml::001::venkata
  D: customers table created

Changeset db/changelog/changes/001-create-customers.yaml::002::venkata
  D: idx_customers_email created

The below example shows how to use Liquibase from the command line to check status, apply updates, and perform rollback operations - which is essential for CI/CD pipelines and zero-downtime deployments.

It gives the following output,

# status output:
3 changesets have not been applied to appdb
  db/changelog/changes/002-create-orders.yaml::003::venkata
  db/changelog/changes/002-create-orders.yaml::004::venkata
  db/changelog/changes/003-add-status.yaml::005::venkata

# update output:
Running Changeset: 002-create-orders.yaml::003::venkata
Running Changeset: 002-create-orders.yaml::004::venkata
Running Changeset: 003-add-status.yaml::005::venkata
Liquibase command 'update' was executed successfully.

# rollbackCount 2 output:
Rolling back changeset: 003-add-status.yaml::005::venkata
Rolling back changeset: 002-create-orders.yaml::004::venkata
Liquibase command 'rollbackCount' was executed successfully.

# updateSQL (dry run) output:
-- Changeset 002-create-orders.yaml::003::venkata
CREATE TABLE orders (id BIGINT AUTO_INCREMENT PRIMARY KEY, ...);
-- Changeset 003-add-status.yaml::005::venkata
ALTER TABLE orders ADD COLUMN status VARCHAR(20) NOT NULL DEFAULT 'PENDING';

Liquibase vs Flyway - When to choose each:

Choose Flyway when your team is comfortable with plain SQL, you have a single database engine, and you want a simple, lightweight tool with minimal configuration. Flyway is easier to learn and integrates seamlessly with Spring Boot.

Choose Liquibase when you need database-agnostic changelogs (same changelog deployed to MySQL in dev and Oracle in prod), require strong automated rollback support in CI/CD, or need the richer auditing and context-based deployment features that Liquibase provides through its contexts and labels feature.