Liquibase Persistence Layer

Make Your Persistence-Layer Production-Ready with Liquibase

Software developers working on different systems or applications usually start small or from scratch. During the development they focus on the requirements and making things work (functional). However, once the project reaches maturity, things tend get challenging. Thankfully, Liquibase can help.

There are so many production-related problems that are not visible during the development. But we are here to focus on “Persistence”-related problems.

Issue#1: Multiple Environments

Let’s assume you have 1 project. For this example, we can call your project: Project Cement. During Project Cement’s production phase, if the team will be following the SDLC V-Model where each phase corresponds to a testing phase, the project will be needing the following environments.

  • Local environment
  • Team environment
  • User-Acceptance Test (UAT) environment
  • Production environment

Now we have 4 environments, and this is just the usual setup. There’s a possibility that the project requires more depending on the situation.

But wait there’s more, our problem doesn’t end there. For each environment, there’s a possibility of having multiple databases and multiple schemas.

Maintenance = No. of Environments * No. of databases * No. of Schemas

In translation, this formula simply means it is hard to maintain.


Developer 1 was assigned to create a feature that requires a schema change, he/she finished the task, tested his changes on his local environment and everything was working fine. He applied the new feature to the team environment where the team QA will perform extensive testing.

Developer 1 being agile and eager, wants to utilize his working hours and started on a new task.

After a while, the team QA announced that the feature is now ready for UAT environment.

Developer 1 working on a new task, was too busy. He/She applied/pushed the code changes to UAT environment, but forgot the schema changes. Therefore, the feature he created failed miserably on UAT environment. Now, imagine that happening on production environment where there’s higher risk.

Moral of the story: Multiple changes are hard to maintain and prone to error.

Solution: Package the schema change with the project codes with Liquibase because it is a tool that can manage database schema by having the versioning feature which makes schema, easier to refactor/change, rollback in case of a problem and deploys on multiple environments.

Issue #2: Migration to another RDBMS (Relational Database Management System)


Project Cement was already in production, and the client has decided that instead of using open-source solution. They want to use a proprietary (paid) product. This means that Project Cement’s persistence layer will be migrated from a free one MySQL Database to Oracle Database.

With the given deadline, Developer 1 escalated that it will not be feasible, and will require a lot more work to migrate. The client was persistent, and still pushed the migration. Developer 1 was left with a tremendous workload to migrate everything while asking himself “Why??”.

Solution: Developer 1’s misery should have been avoided, if the team used Liquibase. Simply because it is a tool with the ability to adjust to multiple types of RDBMS, where it has the attribute of liquid (which is self-explanatory). It can adjust/take shape of whatever RDBMS the project requires.

Issue #3: Creating a fresh database

Having an existing system, with multiple environments, developer 1 was asked to create a new environment. The problem is that all the existing environment has existing data so developer 1 only have 2 options.

  • Option 1: Create a SQL dump that contains only the schema
  • Option 2. Create a SQL dump that contains everything and delete the unnecessary data.

Both options will consume more time than expected. Option 1, will require the initial data for system initialisation such as Admin account and application config/whitelist/secrets. Option 2, then, contains everything but deleting the unnecessary data is prone to error and re-work.

Solution: Use Liquibase, because it’s a tool with the ability to do, versioning, for both schema and data change. Simply run it and everything you need will be there.

How to integrate Liquibase with your project

(This will be the standalone Liquibase flavor, as it can easily be added to your CI/CD automation pipeline. For alternatives, you can also check the maven implementation).

Step 1: Create the following folders inside your repository that contains the XML Liquibase script.

This might be the most simple and easiest step on the list, so enjoy it.

Step 2: Inside the config folder

You can have multiple environment config and credentials.

Set accordingly the database credentials , , <url/schema>

Step 3: Under drivers folder

Add drivers of the databases of your choice. (Note this will be used on config under driver and classpath properties.)

Step 4: Under db-updates folder, create the following files.

changeset-master.xml contains the execution included script files to be executed by liquibase.

changeset-update-01-create-tables.xml contains the scripts for creating tables.

Changeset-update-02-default-data.xml contains the script for creating default data such as admin account / initial configuration

SELECT COUNT(*) FROM service WHERE code = ‘default’;

code = ‘default’

Step 5: Under executable folder extract liquibase– that can be downloaded on their website


Step 6: Tag (snapshot current version) the database before running Liquibase so that you can perform a rollback.

By executing while on Liquibase/executable folder

java -jar liquibase.jar –defaultsFile=../config/ tag freshdb

Step 7: Execute update that will create tables and default data

java -jar liquibase.jar –defaultsFile=../config/ update

Step 8: (Optional) When there’s a problem, perform a rollback.

java -jar liquibase.jar –defaultsFile=../config/ rollback freshdb

– You can create multiple Liquibase scripts just add it to the changeset-master.xml

– Take note of the “id” attribute because Liquibase will run it in sequence

– when you mess up, it’s easier to re-create schema and run Liquibase.

John Morales
Sr. Java Developer


Read Next: The Truth About Game Development

Here at Monstar Lab Philippines, we encourage our engineers, developers, and practically all team members to share technicals skills, development hacks, and industry knowledge to the entire family.

We conduct regular Tech Talk Tuesdays (or Thursdays) more popularly known as T3 Sessions.

This helps us keep our minds sharp and always up to date with the latest in software development, mobile development, and emerging technology.

You can count on the expertise of our team to design and deliver top-notch enterprise software solutions. Feel free to send us a message anytime and we’ll help you out.

Tags: No tags

Add a Comment

Your email address will not be published. Required fields are marked *