Database Migration tools: Flyway vs Liquibase

I believe that there is no need for describing why the usage of database migration tools is vital for modern days apps that utilize relational database engines. I will only say that they can make our life much easier and help us to automatize a complex and repetitive process.

Through the course of this article, I will provide some more insights into the similarities and differences between two of the most common open-source migration tools, namely Flyway and Liquibase.

I will start with quick descriptions of both tools.

The two most popular migration tools, Flyway and Liquibase, deliver version control for databases. Flyway uses SQL or Java for defining a change. In contrast, Liquibase provides flexibility for writing changes in SQL, XML, YAML, and JSON formats.

Details of Flyway

It is described by its creators, a company called Redgate, as an open-source database migration tool that prefers simplicity and convention over configuration. 

As of now, it supports most of the currently used database engines, such as Postgres, Oracle, SQL Server, DB2, H2, MariaDB, and many others. It also supports some cloud base database services like Amazon RDS or Google Cloud SQL or Heroku. 

The script can be written in pure SQL (many dialects are supported) or in Java (mostly for more complex transformations). It has a command line client but it also provides Maven and Gradle plugins. 

What is more, it has Java API which also works for Android. 

For those of you who use .NET and C#, there is a Flyway counterpart named Evolve so if you are interested you can check this one up. The link to its GitHub page will be at the end of the article.

Details of Liquibase

It started in 2006 and is an open-source tool for database migrations. 

It is based on the concept of changelogs and changesets files which can be written in SQL, XML, YAML, JSON. There we store all the changes which we want to make in our database structure. These files can be further used to apply those changes to any other database instance.

 Liquibase supports subsequent databases: Postgres, Oracle, DB2, H2, MariaDB, SQL Server, SQLite, and many others. Many cloud-based databases are also supported for example Azure SQL, Amazon RDS, Amazon Aurora. 

You can run Liquibase migration scripts from shell, using build tools such as Maven Gradle or even Ant. Moreover, you can generate pure SQL queries that can be further executed by your DBA-s/Ops/DevOps team or anyone who is taking care of your database.

Now that we described both tools, we can move to describing similarities and differences between them. Let’s start with the similarities between these two tools.

Similarities Between Flyway and Liquibase

• Both are to some degree open source and provide some part of features for free but also have paid versions that provide more features.

• Both can use plain old SQL to write your migration scripts.

• Both are strongly "Java oriented" and also have built in support for basic build tools like Maven or Gradle as well as integration with the most common Java frameworks, for example: Spring Boot.

• Both can be run as simple shell scripts from command line.     

• The list of supported databases is more or less similar. There can be some minor differences in supported versions or drivers but in general, there are no easily visible differences between them in this area.

• Both are based on the same approach for handling database changes, namely Migration Based Database Delivery.

• Both tools try to implement the concept of Evolutionary database presented and explained by Martin Fowler (link in the end of the article).

Here we have all similarities between these tools. Now we can proceed to describing the differences between them. 

I will start with cross database usage – the possibility to run the same scripts across multiple database engines. 

Then I will try to answer the question which I actually faced in my professional work which is: Which tool could I use to compare two instances of the same database and generate diff between them. 

In the third subparagraph, I will mention Flyway Java client which seems to be quite a powerful and useful feature. 

The fourth paragraph will be about rollbacks. I will end this comparison with deep dive into managing the order of changes by each tool.

Differences Between Flyway and Liquibase

1. Cross-database usage   

   Both tools give you the possibility to write migration scripts in pure SQL so as long as you use it you have to customize your scripts while doing migrations across different database engines. However,  you will have the possibility to use ‘magic’ or queries with keywords existing in a specific engine which can greatly increase your database performance. If you decide to use Liquibase and write your scripts in one of other supported formats you should easily be able to use the same scripts across different databases.

2. Diff generation

   You can do generate diff with Liquibase but not with Flyway, even with  its paid version. It was one of main reasons why we chose Liquibase over Flyway in our project.

3. Integration

   As I mentioned in the paragraph describing similarities, both tools are almost the same in this area. There is one but very important difference here, which I would like to mention. Flyway has a native Java API. It is designed to help us with more complex migrations like BLOB and CLOB changes or advanced bulk data changes. This API can be very useful in some cases and may be the reason to choose Flyway over Liquibase.

4. Rollbacks

   Now it is time to describe how our tools handle rollbacks. On one hand, they are relatively easy to set up in Liquibase changelog files. In fact, there is even a special field defined in changelog XML structure for rollback code. On the other hand, in Flyway it is only available in the paid version. Unfortunately, I did not have an opportunity to use it, so I am not able to make a full comparison here. If you are willing to pay for your tool, it can be worth it to delft in this Flyway feature. However, the paid version of Liquibase supposedly has even more complex support for different kinds of rollbacks so it also is worth checking.

5. Change order management   

   The last thing that I want to mention and compare is managing the order of changes. Here both tools have a totally different approach. Flyway is based on concepts of linear database versioning. It means that the order of applied changes depends on migration scripts names. In fact, there is a whole naming convention for Flyway migration scripts, which you must follow if you want it to work as expected. In Liquibase the order of applying changes to our database instance is based on a particular change location in the overall changelog file. You can be sure that if you put your changes in some order within the changelog you will have your changes applied in exactly the same order in your database.

Summary

I described some similarities and differences between Liquibase and Flyway trying to be as unbiased and objective as I can. This article should give you some more insight into the workings of both tools and possibilities provide by them. The final decision on which one to choose is yours.

Links

• Martin Fowler “Evolutionary Database”
• Evolve GitHub page
• Full list of databases supported by Liquibase
• List of Flyway supported databases under bookmark “Supported D