Flyway - first impressions

What is Flyway?

Flyway is a "agile database migration framework for Java".

Why Flyway?


  • it uses SQL as its primary "language" for patches (no XML awkwardness)
  • we do not have nor a very complicated DB schema neither a complicated development/branching/whatever process,
  • we do not plan to migrate to another database (BTW. I have been in enough projects where we did things because maybe/baby one day we need to change our DB server to something else, and guess what? we never did!)
  • it looks simple, and it does not try to do too much
  • it supports PostgreSQL

First impressions

First of all, the learning curve is flat (comparing to Liquibase). Flyway is simple to use. The documentation is really helpful. There is not much you have to do to have it up and running.

In our scenario we run Flyway programmaticaly (as a part of a larger deployment task). In general I can say it was pretty simple to start using it. The only thing that is a real PITA is the idea of Flyway looking for SQL migration files on the classpath. I do not say it is bad, but it would be so much nicer to be also able to specify that the patches should be searched for in /home/user/patches. I opened an issue for this

It is easy to configure Flyway, so for example we use patches with different prefix for schema (which is used to populate production DB) and for data (which are used only for the convenience of developers so the system on local machines starts with some reasonable data).

Not sure if my opinion of Flyway will be the same in few months, but right now I'm very happy with it. :) At least it suits me much better than Liquibase (which I had used a little bit in previous projects).

You are right, migration to

You are right, migration to the another database platform during application lifecycle is very unlikely.

But what if you use different databases for local development and for production? I found that Liquibase is extremally powerful in that scenario:

h2 - integration tests
mysql - local development
oracle - qa / production

There is a Groovy DSL for Liquibase to avoid XML hell but I have not tried yet.


been there done that :)

Hi Marcin,

I do not see a problem here - as long as your patches are "clean" SQL (without any vendor-specific enhancements) than you can apply it to any database.

And BTW. in my current project we use different approach. We use PostgreSQL for everything, which means every dev has his own PostgreSQL server on local machine. Works pretty well, and gives more confidence in what we do.

Tomek Kaczanowski

Hi Tomek In practice clean

Hi Tomek

In practice clean SQL means one database vendor. How to handle varchar2 / varchar, blobs differences, date formats, sequences / autoincrement, constraints enabling/disabling etc. ?

PostgreSQL, you are lucky :-) Oracle for the local development kills developer productivity, for integration tests / continuous integration the situation is even worse.

From the testing perspective I agree that single database vendor for the whole delivery process is much better. Keep your development environment as close to the production as possible - that's the key.


No Hibernate support

And no hibernate support...?

Lack of downgrade support

Hi Tomek,

Flyway looks nice. Thanks for writing about it.
How do you cope with lack of downgrade support?

Downgrade is not easy, but sometimes essential: whole feature needs to be rolled back, migration corrupted DB schema.


don't do downgrades

Hi PawełR,

my world must be a uniquely happy place, because as for now I do not have problems with downgrades. :) Maybe because we are at an early phase of the project, maybe because we have a strong test (or maybe pre-production) environment which helps to fix issues before they pollute production.

Tomek Kaczanowski

This used to be my blog. I moved to long time ago.


Please comment using