How Liquibase Makes Life Easy for DB Admins

Let’s be honest - managing database changes can sometimes feel like juggling fire. You’ve got multiple developers making updates, environments to manage, rollbacks to worry about, and let’s not forget those late-night “It worked on dev!” surprises. But guess what? There's a tool that can help you stay ahead of the chaos. It’s called Liquibase, and it's like having a helpful assistant who always remembers what changes were made, who made them, and when. Today, we're going to break it down - what Liquibase is, how it works (especially with YAML), why it's useful, and how it's being used in real projects like mux-sql. So grab your favourite cup of coffee ☕️, and let’s dive in! What is Liquibase? Liquibase is an open-source database change management tool. Think of it as version control, but for your database. Just like Git helps developers manage changes in their code, Liquibase helps you manage changes in your database schema. It keeps track of all the changes you've made (like adding tables, modifying columns, or creating indexes) and applies them in a controlled, consistent way across different environments - dev, test, staging, production. And yes, it works with most major databases: MySQL, PostgreSQL, Oracle, SQL Server, and many others. Why Should You Care? You might be thinking, “My team already handles DB scripts manually. Why switch?” Here’s why Liquibase can make your life easier: No More Manual Scripts: Say goodbye to writing and tracking V1__create_table.sql, V2__add_column.sql, and so on. Tracks What’s Been Applied: It keeps a changelog and logs every change in a special table (DATABASECHANGELOG) inside your DB. Works with CI/CD: Automate your DB updates during deployments. Supports Rollbacks: Made a mistake? You can roll back changes with a command. Clear Audit Trail: Know who changed what and when. In short, Liquibase gives you control, clarity, and confidence when managing DB updates. How Does It Work? Liquibase works using something called a changelog. This is a file where you define all your database changes using a format like YAML, XML, JSON, or SQL. Each change is grouped into a changeset—a small, trackable unit of change. Here's an example from the mux-sql app's Liquibase YAML file: databaseChangeLog: - includeAll: path: sql relativeToChangelogFile: true - changeSet: id: product-table author: claude labels: products-api comment: Creating product table for REST API changes: - createTable: tableName: products columns: - column: name: id type: SERIAL constraints: primaryKey: true - column: name: name type: VARCHAR(100) constraints: nullable: false - column: name: price type: NUMERIC(10,2) constraints: nullable: false defaultValue: 0.00 This snippet says: “Hey, create a table called users with id, username, and email columns. The id is the primary key and cannot be null.” Once you run Liquibase, it reads this changelog, checks which changes haven’t been applied yet (based on the DATABASECHANGELOG table), and runs the SQL under the hood to make the changes. Easy, right? YAML + Liquibase: A Perfect Match made in heaven Many DBAs are familiar with SQL, but YAML might feel new. Don’t worry - YAML is just a human-readable way to structure data. It’s like writing your changes in plain English. Why use YAML? It’s clean and readable. Great for code reviews. Less error-prone than long SQL scripts. Supported natively by Liquibase. If you’ve ever worked with configuration files in Kubernetes, Docker Compose, or CI tools like GitHub Actions - you’ve already used YAML. You’re ahead of the game! A Real-World Example: Mux + PostgreSQL Let’s talk about something real. The mux-sql project uses Liquibase with a YAML changelog to manage its database schema. It's a backend app built with Go, and like many projects, it needs to manage a growing database as new features are added. Here’s how they’ve set things up: They use a liquibase.yml file in the root of their project. All database changes (like new tables, updates) are defined inside it. Developers make schema changes by adding new changesets. When the app is deployed, Liquibase applies only the new changes. The team doesn’t have to guess what version the database is on—Liquibase handles it. This approach keeps things clean, consistent, and avoids the “Did we run that script on staging?” drama. CI/CD and Liquibase = New Power Duo Now, let’s level up, iIf your team is using a CI/CD pipeline (like GitHub Actions, GitLab CI, or Jenkins), you can run Liquibase automatically whenever you deploy. I

May 7, 2025 - 07:44

How Liquibase Makes Life Easy for DB Admins

Let’s be honest - managing database changes can sometimes feel like juggling fire. You’ve got multiple developers making updates, environments to manage, rollbacks to worry about, and let’s not forget those late-night “It worked on dev!” surprises.

But guess what? There's a tool that can help you stay ahead of the chaos. It’s called Liquibase, and it's like having a helpful assistant who always remembers what changes were made, who made them, and when. Today, we're going to break it down - what Liquibase is, how it works (especially with YAML), why it's useful, and how it's being used in real projects like mux-sql.

So grab your favourite cup of coffee ☕️, and let’s dive in!

What is Liquibase?

Liquibase is an open-source database change management tool. Think of it as version control, but for your database.

Just like Git helps developers manage changes in their code, Liquibase helps you manage changes in your database schema. It keeps track of all the changes you've made (like adding tables, modifying columns, or creating indexes) and applies them in a controlled, consistent way across different environments - dev, test, staging, production.

And yes, it works with most major databases: MySQL, PostgreSQL, Oracle, SQL Server, and many others.

Why Should You Care?

You might be thinking, “My team already handles DB scripts manually. Why switch?”

Here’s why Liquibase can make your life easier:

No More Manual Scripts: Say goodbye to writing and tracking V1__create_table.sql, V2__add_column.sql, and so on.
Tracks What’s Been Applied: It keeps a changelog and logs every change in a special table (DATABASECHANGELOG) inside your DB.
Works with CI/CD: Automate your DB updates during deployments.
Supports Rollbacks: Made a mistake? You can roll back changes with a command.
Clear Audit Trail: Know who changed what and when.

In short, Liquibase gives you control, clarity, and confidence when managing DB updates.

How Does It Work?

Liquibase works using something called a changelog. This is a file where you define all your database changes using a format like YAML, XML, JSON, or SQL. Each change is grouped into a changeset—a small, trackable unit of change.

Here's an example from the mux-sql app's Liquibase YAML file:

databaseChangeLog:
  - includeAll:
      path: sql
      relativeToChangelogFile: true
  - changeSet:
      id: product-table
      author: claude
      labels: products-api 
      comment: Creating product table for REST API
      changes:
        - createTable:
            tableName: products
            columns:
              - column:
                  name: id
                  type: SERIAL
                  constraints:
                    primaryKey: true
              - column:
                  name: name
                  type: VARCHAR(100)
                  constraints:
                    nullable: false
              - column:
                  name: price
                  type: NUMERIC(10,2)
                  constraints:
                    nullable: false
                  defaultValue: 0.00

This snippet says: “Hey, create a table called users with id, username, and email columns. The id is the primary key and cannot be null.”

Once you run Liquibase, it reads this changelog, checks which changes haven’t been applied yet (based on the DATABASECHANGELOG table), and runs the SQL under the hood to make the changes. Easy, right?

YAML + Liquibase: A Perfect Match made in heaven

Many DBAs are familiar with SQL, but YAML might feel new. Don’t worry - YAML is just a human-readable way to structure data. It’s like writing your changes in plain English.

Why use YAML?

It’s clean and readable.
Great for code reviews.
Less error-prone than long SQL scripts.
Supported natively by Liquibase.

If you’ve ever worked with configuration files in Kubernetes, Docker Compose, or CI tools like GitHub Actions - you’ve already used YAML. You’re ahead of the game!

A Real-World Example: Mux + PostgreSQL

Let’s talk about something real.

The mux-sql project uses Liquibase with a YAML changelog to manage its database schema. It's a backend app built with Go, and like many projects, it needs to manage a growing database as new features are added.

Here’s how they’ve set things up:

They use a liquibase.yml file in the root of their project.
All database changes (like new tables, updates) are defined inside it.
Developers make schema changes by adding new changesets.
When the app is deployed, Liquibase applies only the new changes.
The team doesn’t have to guess what version the database is on—Liquibase handles it.

This approach keeps things clean, consistent, and avoids the “Did we run that script on staging?” drama.

CI/CD and Liquibase = New Power Duo

Now, let’s level up, iIf your team is using a CI/CD pipeline (like GitHub Actions, GitLab CI, or Jenkins), you can run Liquibase automatically whenever you deploy. Imagine this:

A developer creates a new table.
They add a new changeset to the YAML changelog.
They push their code.
Your CI pipeline runs, and Liquibase applies the new schema changes as part of the deploy.

Boom! Database updated, and everyone’s happy. No more hunting down SQL scripts or forgetting to run migrations.

But what About Rollbacks?

Mistakes happen. Maybe a changeset dropped the wrong column. Don’t worry—Liquibase has rollback support.

You can define a rollback inside your changeset like this:

databaseChangeLog:
  - includeAll:
      path: sql
      relativeToChangelogFile: true
  - changeSet:
      id: product-table
      author: claude
      labels: products-api 
      comment: Creating product table for REST API
      changes:
        - createTable:
            tableName: products
            columns:
              - column:
                  name: id
                  type: SERIAL
                  constraints:
                    primaryKey: true
              - column:
                  name: name
                  type: VARCHAR(100)
                  constraints:
                    nullable: false
              - column:
                  name: price
                  type: NUMERIC(10,2)
                  constraints:
                    nullable: false
                  defaultValue: 0.00
      rollback:
        - dropTable:
            tableName: products

Now, if something goes wrong, you can just run:

liquibase rollbackCount 1

And it will undo that change. Peace of mind, built-in.

Best Practices for DB Admins Using Liquibase

Here are a few tips to make the most of Liquibase:

Use descriptive id and author in each changeset helps trace who did what.
Keep changelogs in version control (Git) treat schema as code.
Test locally before pushing changes always!
Use Liquibase commands to validate before applying changes: liquibase validate
Modularize your changelogs if your project gets big. You can include files.

The Learning Curve? Not So Steep!

Some folks might worry that using Liquibase adds complexity. But in practice, it actually reduces complexity. No more guesswork. No more broken SQL files. No more “It worked on my machine.”

Instead, you get:

A single source of truth.
Audit history of every change.
Easy rollbacks and repeatable deploys.

Once you use it on a few projects, it becomes second nature.

Conclusion

Liquibase is like the superhero sidekick you didn’t know you needed. It helps you:

Track database changes.
Apply them in a consistent way.
Roll them back when things go sideways.
Work better with your team and CI/CD pipelines.

If you’re a DB Admin tired of manual SQL chaos, it’s worth giving Liquibase a try. The mux-sql project shows just how clean and simple a YAML-based changelog can be. You’ve already got the skills - Liquibase just helps you use them smarter. So go ahead - set up that liquibase.yml, commit it to Git, and start managing your database like a boss.

❓ FAQs

1. Do I need to know Java to use Liquibase?

Nope! Liquibase is built in Java, but you don’t need to write any Java code to use it. You just need the Java Runtime Environment (JRE) installed to run the Liquibase CLI. Everything else like - YAML, SQL, or XML changelogs is what you already know.

2. Can I use Liquibase with my existing database?

Yes. Liquibase can integrate with an existing database by using the generateChangeLog command to capture the current state. From there, you can start tracking future changes incrementally with changesets.

3. What if I accidentally apply the wrong changeset?

That’s where rollback comes in. If you’ve defined a rollback block inside the changeset, you can undo changes safely using a simple command like:

liquibase rollbackCount 1

Without a defined rollback, you’ll need to handle it manually—but Liquibase will still show you what was applied and when.

4. Can multiple developers work on the same changelog?

Yes, but with structure. Each developer should add their own changesets with unique ids and authors. Keeping changelogs in version control (like Git) and modularizing them with include files helps avoid merge conflicts.