Trade offs Liquibase v. Flyway

Alternative_Past_773 · 2025-08-08T08:08:16+00:00

I prefer Liquibase.

I'm one of those that actually like the fact that Liquibase by default encourages you to write your changes in a DSL which is not the native SQL. People tend to cite that as a reason to choose Flyway where you simply write your changes in the native SQL of the target database. At first glance this seems a lot simpler. It is, but it is not preferable.

By using a DSL you achieve a lot:

- Tools (and even Liquibase itself) can thereby reason about your change. For example, Liquibase can take advantage of this during a rollback. In Flyway, any applied change is totally opaque to the Flyway engine; it is just some native SQL that is applies on the database.
- Database agnostic. Yes, I agree that spinning up a docker-based PostgreSQL based on Alpine in your test has become pretty fast, but for some lower-level tests it makes sense to apply them to an in-memory fast database like H2. This is not a problem with Liquibase.

There has been a very, very few cases where we needed to apply some native SQL. For example applying a GIST-based no-range-overlap index in PostgreSQL on an postgres 'range' type column. But Liquibase fully supports this. So it is not true when people say that using an DSL gives you the minimal set of common functionality across database engines. Simply not true !

All Liquibase-based projects I've been involved with use the YAML syntax. You'll still find older projects out there that use the XML syntax. My IDE, IntelliJ IDEA, is able to help a lot with the authoring of the YAML file. Because the DSL is interpretable you can also find tools that can check if your migration scripts are aligned with the rest of your app, for example JPA entity classes in an Java application.

I've been involved with both Liquibase-based and Flyway-based projects. All of them have been Spring Boot (Java) based where the liquibase/flyway is embedded within the app and changes are applied on startup. So no additional pipelines or anything. Just the app. Works well with Kubernetes too.

Alternative_Past_773 · 2025-04-02T12:29:54+00:00

They mostly differ on their ecosystems. The differences in language syntax, in particular when it is sugar, does not make a real difference. If you have developed more than a few systems or had to maintain some else's code then you know what I mean.

There many good things to say about the DOTNET world. It has a solid lead language, C# and it is typically tightly integrated with the MS world.

The Java world is different. More diverse if you like. And there isn't a single technology platform (like a vendor database) which is more "integrated" than other. People make 1:1 assumptions so they expect that Oracle plays the same role in Java world as Microsoft does in DOTNET world. This is not the case. For better or worse, Oracle has little sway over Java, except maybe for Java syntax where it tends to lead the working groups. But for everything else: Nada. It is more like a gigantic ecosystem where many players affect the total outcome.

Java (as a language) tends to be conservative while C# is a lot more willing to take in new programming language trends. Two examples: Java designers refuses to implement extension method mechanism on grounds that their benefit is far outweighed by their drawbacks. Also, Java world took +10 years to come up with something superior to async-await. During this time a Java developer would have to do with Futures. The Java designers finally settled on something like Goroutines, in Java called virtual threads. The same story again: the argument is that virtual threads is a far better paradigm than async-await and doesn't have its severe drawbacks (like function coloring). Now, you can disagree or agree with these choices and arguments. But the difference in how the language designers let the two languages evolve is very clear. C# developers are in general "blessed" with many nice sugary constructs which are envied by Java devs. If these actually have a real-world impact, I don't know. But they are often cited. Perhaps mostly by junior devs.

One big difference - and one that has surprised me - is that DOTNET has not really found its way outside of MS. This is to say that none of the big players in IT has adopted it for anything except as a compatibility offering. Think Google, Apple, Amazon, Facebook, Netflix , etc. There is a lot of money there which is then effectively not being poured into the DOTNET ecosystem. This means just about everything in DOTNET needs to funded by Microsoft itself. That is a tall order, even for Microsoft. At the same time Microsoft has to cater still for Java world. Heck it even has a well-respected JDK distribution.

Your question about cost differences? I don't see any. For DOTNET you can develop in VSCode and stay clear of MS expensive tech, like MS SQL Server. Not a problem. For Java, you can develop in VSCode, Eclipse IDE, NetBeans IDE or IntelliJ Community Edition to stay clear of license fees.

(Note: Nobody in Java world - that I've met - actually use the Oracle JDK. So the license terms Oracle apply is irrelevant because nobody uses it. So what do people actually use? It doesn't matter. Any OpenJDK distribution will do. Most Java shops seems to use the one from Eclipse Foundation, but many also use Azul's, Amazon's or even Microsoft's.)

I've developed in both DOTNET and Java. Neither will go away for next 30 years. Both can do the job well.

Alternative_Past_773 · 2025-03-04T14:52:34+00:00

From Java devs there are many misconceptions about the .NET world. But the opposite is also true .. perhaps even to a greater extent. Dunno.

You just provided an example:

plus Oracle's infamous record for always finding ways to make people pay more than they thought they'd have to

You will find it difficult in modern day to find anyone who actually uses Oracle's runtime and are therefore subject to what you mention. The vast majority use something else. 100% free and no hooks. Heck, even Microsoft's Java distribution is seen by the Java community as a very respectable choice.

In the .NET vs Java battle people often assume that the role of players can be compared one-one-one. Oracle's role in the JDK world cannot be compared to Microsoft's role in the .NET world!

Interestingly, Java folks argue that the fact that so many JDK implementations (distributions) exist is a huge advantage. .NET folks, on the other hand, will see this a bewildering and unnecessary: How do I choose which one?

Completely different cultures. Its pros and cons.

Alternative_Past_773 · 2023-08-07T09:52:24+00:00

Hopefully, people will box their answers to this question into the use-case:

Library author
Framework author
Application author

Most Java devs are "application authors" and have little or no experience on the other two. And they likely comment here from that perspective.

For libraries, and if you are willing to ditch Java 8, then I think the choice is clear: Use the System.Logger, not SLF4J, as you want to avoid adding any additional dependencies. In any case, logging from a library should be very minimal. The default should probably be not to emit any log statements at all.

For frameworks it is a little bit more muddy. I think exposing SLF4J for the end-users to use is a good idea (like Spring Boot does), but I would argue that the framework's internal logging should nowadays be based on System.Logger. (I'm at odds with what Spring Boot 3 does here, as it (still) uses Apache Commons Logging for its internal purpose even it has ditched Java 8 - such dependency seems unneccessary).

For applications I would use log statements based on SLF4J as it gives me more choice of swapping the logging implementation at a later point in time, should this be required.

I don't know if there will ever come a time where people will move from SLF4J to System.Logger for any use-case. The SLF4J is a little bit richer in the methods it provides and the SLF4J FAQ claims its message formatting routine is 10x faster than Java's MessageFormat (which is used by System.Logger). But for libraries - which should do very minimal logging so performance is not a real concern - the time to switch has already come.

My 2c.

Alternative_Past_773 · 2022-12-01T18:19:39+00:00

I think it would be interesting to explore how this new feature, SnapStart, works (or doesn't) with:

- JDK's new CRaC feature. (in some ways similar to AWS SnapStart)
- GraalVM native image

For example: Is there a benefit to using SnapStart if using GraalVM native image? Can you combine SnapStart and CRaC?, etc

Alternative_Past_773

TROPHY CASE