Database Migrations with Liquibase and Flyway

A comparison between tools

Photo by Aryan Singh on Unsplash

As a software developer, I want to automatize my relational database migrations on test, staging or production environments. To achieve that, I have tested two migration tools widely know on Java universe: Liquibase and Flyway.

The stack behind this test project was:

• Spring Boot & Java 11 application.
• MySQL database.
• Maven plugin to run both Liquibase and Flyway.

Some background

Database changes can be painful and destructive, not only on monoliths but especially on distributed systems. I have found some recommendations about the best practices, such as the article “Evolutionary Database Design” by Martin Fowler and this talk plus book by Edson Yanaga.

Roughly, the important things are:

• To keep database scripts versioned with the application code.
• To keep backward and forwards compatibility. For example, a table column can not be renamed right away. It is necessary to have intermediate states between this action: add a new column, write in both columns during version 1.x, change the code to read the new column during version 2.x and drop column during version 3.x.

Automate tasks

I do not want all my team to have direct access to test, staging or production databases and also I do not want to execute scripts manually. Liquibase and Flyway will play this role and all I need to do is to write the scripts.

Since I have tested the free version of both tools with MySQL database in a Spring Boot project and Maven plugin, I will summarize their functionalities and why I have chosen one instead of another.

There are plenty of articles focused on Liquibase and Flyway, so I will not extensively talk about them.

You can check these two separated stories for a brief overview:

• here is Flyway’s and
• here is Liquibase’s.

And the chosen one is…

In my humble opinion, both tools are great and they do the job. However, I decided to go for Flyway.

I do not believe I will ever need the all functionalities that Liquibase offers and it was a little bit more painful to configure and run it than Flyway. Also, I always found XML files kind of messy/ugly. sorry

For XML files, it is necessary to respect a pattern, worry about the mandatory tag databaseChangeLog and its version. I got some errors with the changelog file because I have started with an older version of Liquibase. When I updated it, it was necessary to change the version on XML files.

I know it is not a biggie but there is no need to do that with Flyway.

Also, the configuration (flywayConfig.properties) felt simpler and cleaner than Liquibase’s (liquibase.properties). Perhaps because there are not as many options as on Liquibase. I do not really need all the functionalities that Liquibase offers, so instead of helping they were just creating some noise.

For instance, in the beginning, I was not sure why there were two similar properties: changeLogFile and outputChangeLogFile. This concern did not exist with Flyway.

After having it “installed”, the only thing to do with is to place scripts on the configured folder respecting a sequence for the migration files’ name. No additional worries.

Flyway does the job straight away and it is much more intuitive than Liquibase. It is easier to simply write SQL in a way that everybody is already used to and thus, there is no learning curve.

Flyway is the most “lightweight” and trouble-free solution to automatize the database migrations.

Originally posted on my Medium stories.