Flyway and liquibase together?

Question

I've looked at both Liquibase and Flyway individually and on an individual comparison alone, Liquibase seems like the better tool for our needs. Some sources mention using both Liquibase and Flyway together. Liquibase seems to have everything Flyway has and more flexibility when it comes to rollbacks. The main advantage of just Flyway seems to be not having to use XML, but Liquibase allows you to specify an SQL file in their XML.

Basically, I'm still not clear on what the benefits of using Flyway & Liquibase together would be over just Liquibase, if there are any. Maybe there's a way to do it I'm not seeing as even if Liquibase was referring to valid Flyway SQL files, both tools would have to be run independently and still have the same pitfalls even though you could technically use either tool.

Solution 1

A small correction, before I answer question. The assumption

Liquibase seems to have everything Flyway has

isn't correct. Flyway shines when it comes to parsing SQL. You can use unmodified SQL files generated by your native tools containing all kinds of complexity like PL/SQL packages and procedures, MySQL delimiter changes, T-SQL, PostgreSQL procedures, ... With Liquibase you would have to split these in individual statements, add extra comments to the SQL files, ...

The beauty of being able to use your SQL files as-is is that you avoid lock-in. You can take your existing SQL files, start using Flyway with minimal investment and moved away later if it doesn't suit your needs anymore. Not so with Liquibase.

Also the issue of down migrations (think of them as compensating transactions, not rollbacks) is really something that sounds great in theory, but that is almost never needed in practice. See this old documentation page¹.

However when it comes down to using one or both, I certainly agree with SteveDonie (Liquibase team member) that using just one instead of the both together is almost always the better choice.

Disclaimer: I am Flyway's creator

---

¹ Though Flyway does support undo migrations nowadays, by reading the old documentation you'll understand the point Axel Fontaine is trying to make.

Solution 2

I would never recommend using both tools at the same time. In my experience, even only one of them causes conflicts/collisions from time to time in a big distributed environments(over 5 teams with access to the same DB).

I will also give you a couple of pros and cons when it comes to running these tools in projects with big, distributed teams:

FlyWay:

Cons: Very strict when it comes to migration files changes. If someone checked in their migration file, it is not recommended to change it. It's like using force push in git in shared projects. Changing a migration(either its content or the file's name) will cause a migration failure on every machine that had the previous version of the file. The whole migration pack will need to be run from scratch. In some cases it can take a lot of time.

Pros: Well, what was described in Cons will, at the same time, build up a level of discipline. It might be a reasonable restriction when talking about introducing simultaneous changes by several teams to a production-running application.

Liquibase:

Cons: With a couple of tweaks should allow you to change the existing(applied) migrations. While it can be considered as a benefit, with a lot of people working on the same codebase, extra caution should be exercised. Flexibility comes at a price. It's easier to introduce some "regression" or inconsistency when such "git force push" style of changes is allowed for distributed projects.

Pros: More configurable and more flexible. Might include solutions for NoSql in the future. A couple of useful plugins(hibernate integration, for example).

Comments

[Slayer0248]

Wow, I was not expecting to have such definitive answers on this straight from the creators! Thanks. You're point on rollbacks makes sense and even with liquibase rollbacks are more or less another migration. I feel like practice is where things become more relative. This was to replace a more or less manual process, so really any tool is probably better practice. Since the use case is in a Jenkins job, I feel like there are certain changes in production which would be undesireable and you'd need the reverse operations. Rollback is just a name for a command from my perspective.

[Slayer0248]

I mean you could probably change the name if you want. Rollback's just been adopted and is currently what's in use. No one would call it something else if I started using a different name for it since I've not been establishing the trend. Just my thoughts.

[Rodislav Moldovan]

hey hi, I have serious doubts in your answers, when I see on main page a comparation between a migration tool and a mapper, you cannot compare mybatis with flyway, is like compraing apples with tesla engines, they are like.. doing same thing.. they exist! and vendor lock in.. really ? take your plain old (universal, I guess) sql from postgres and apply it in oracle, you'll get plain old man till you'll get you results with "a breeze" ans liquibase is not only about xml just open the docs.. oh my

[Axel Fontaine]

Have a look at this mybatis.org/migrations :-)

[Gary S. Weaver]

Axel- appreciate your work on Flyway, but I've used Rails alongside Java for more than several years now, and a number of times have utilized one or more rollbacks. While it is "almost never needed", it is needed, and it's good to have the developer write a rollback for each change. Also, in your FAQ, you seem to suggest using backup/restore and snaphots- but that should be the last resort with a DB taking orders and keeping track of work for business. I hope that you'll reconsider the advantages of rollbacks. I'd also advocate non-destructive migrations when possible- rename vs. drop.

[TiggerToo]

The goal is certainly to never have to do a rollback in production, but I use rollbacks constantly in development.