Flyway

Flyway vs Liquibase #Migration #Backwards-compatible

We were looking for a tool to help us integrating the migration scripts as part of our Deployment. At first sight both tools look very alike, are well integrated with Spring, have a fairly frequent development activity and short release cycles.

Liquibase puts a lot of emphasis on independence with the DB, allowing you to create the scripts on formats like JSON and YML, abstracting away from SQL, which it's also supported. Since we only work with one DB type across services we wouldn't take much advantage of this feature.

Flyway on the other hand has the advantage on being actively working on the integration with PostgreSQL 11, for it's upcoming version 6. Provides a more extensive set of properties that allow us to define what's allowed on what's not on each different environment.

Instead of looking for a tool that will allow us to rollback our DB changes automatically, we decided to implement backwards-compatible DB changes, for example adding a new column instead of renaming an existing one, postponing the deletion of the deprecated column until the release has been successfully installed.

We use Flyway because we're convinced, that database schemas (DDL) should be within our version control system. Code and database belong together and Flyway is an easy and powerful way to achieve that goal. The API is easy to use and even though a commercial licence is offered, it is by no means mandatory, which was an important criterion for us.

We also wanted to integrate the migration directly into the code as we run in a serverless environment, where manual migrations are troublesome and the code itself essentially needs to migrate the database, based on its own findings. Flyway offers this capability and we didn't find any other solution, that was as lightweight while still being powerful and flexible.