April 22, 2024

Why leading organizations choose Liquibase over Flyway for database DevOps

So you’re ready to bring DevOps to the database by automating change management. But you’re unsure how to distinguish the leading solution, Liquibase Pro, from an alternative, Flyway Enterprise (Redgate).

Or maybe you’re ready to make the switch from Flyway to Liquibase, and you want to know what to expect from a different tool with advanced capabilities for change management automation, governance, and observability.

Innovative database, application, DevOps, and data teams at organizations around the world turn to Liquibase – it has been downloaded over 100 million times! Liquibase Pro stands out against Flyway Enterprise in a few key ways, including:

Artifact-based deployments (instead of state-based) that empower better collaboration, easier rollbacks, and smaller, more frequent deployments
Advanced DevOps capabilities for better governance, standardized workflows, and visibility for continuous optimization
Expansive database support to expand DevOps automation and best practices to every team, project, and environment, supporting rapidly scaling and flexible pipelines with a single solution

Different approaches to database deployments

The first step to understanding how Liquibase differs from Flyway is to learn about the different approaches to database deployments. Part of the reason for Liquibase’s superior offerings and capabilities is its embrace of artifact-based deployments, an innovative evolution of the migration-based approach. Before explaining this method of deployment and its benefits, let’s review the two most common approaches to deployments: state-based and migration-based.

State-based database deployments involve a tool that compares a snapshot of the database’s current state to an intended future state and then deduces which changes need to be made. Those changes are then merged with the pipeline and the subsequent database deployment includes all of those changes enacted at once.

In state-based deployments, the initial diff script, which outlines the comparison between the current and target states, is the most crucial element. It should contain all the updates needed to reach the desired new state.

Migration-based deployments take a more granular and iterative approach by merging smaller updates with the database pipeline. A series of change scripts is created that outline the explicit, atomic steps needed to bring the database into its updated, intended state. Instead of a single, complex change directive derived from a diff comparison, migration-based deployments make changes one by one in a specific order.

This allows developers to write database code just like they develop application code, pushing smaller, more frequent and manageable changes through a collaborative, version-controlled pipeline that validates and tests before releasing the changes to production.

Liquibase Pro primarily uses migration-based deployments and packages changes into artifacts. By leveraging this artifact-based approach, Liquibase makes it easy to align to DevOps best practices and maximize collaboration, flexibility, and control in database deployments. Liquibase’s artifact-based approach only uses state-based comparisons when appropriate, like drift detection.

Flyway Enterprise relies entirely on state-based deployments – and that causes problems.

The downsides of state-based deployments

Comparing the current database state to the intended state and deploying that whole stack of changes – easy enough, right? Problem is, state-based change derivation makes a lot of assumptions that can cause problems down the line and cancel out the automation benefits upstream.

We’ll use an analogy to illustrate the assumptions made by state-based comparison tools like Flyway Enterprise. Let’s say you currently have a red car and intend to have a blue car in the future.

Ideally, you would just paint your car blue. You (or your paint shop) would follow the logical steps to sand, prep, and paint a new blue shade from bumper to bumper. Think of this as a migration-based approach to getting your blue car.

On the other hand, a state-based approach would look at your current state (red car) and future state (blue car) and deduce that you’ll need to delete (sell) the red car and replace it with a blue car. That approach might reach the desired blue car state, but it’s not the proper execution.

This new car is a blue car, but it’s not your car turned blue. You’re going to go through many more steps to make this one functionally yours. The state-based approach made too many assumptions, which means you’ll have to go back and address the applied changes to avoid problems in the future.

Relying only on state comparisons to derive database changes is risky. Parallel development streams can cause merge issues since comparisons to different databases (QA, staging, prod) or comparisons after changes have unknowingly been deployed will return different and often clashing results. This leaves the door open to misalignment, errors, and delays and brings up a lot of questions, such as:

Which states should be compared?
How is that comparison being made?
Have changes unknowingly been made to either state?
Are your teammates comparing the same states?

A state-based approach also hinders flexibility — because all changes are grouped together, you can’t easily break out changes into subsets if only part of a change request needs attention. This also means teams lose the ability to embrace small, incremental changes, which is fundamental in DevOps principles.

Once all of the changes are generated, Flyway Enterprise stores them as SQL files, and uses the git commit order to derive the naming convention. Flyway’s sequencing is based on filenames, which are implicitly determined by the git commit order, so skipping, rolling back, or reordering changes is a very manual process.

While state-based deployments have their useful place – we’ll cover drift detection and more in just a bit – the migration-based approach is most aligned with DevOps culture and most successfully integrated into CI/CD pipelines.

That’s why Liquibase embraces the migration approach, evolving the method to be even more efficient, flexible, and collaborative with an artifact-based approach.

Liquibase’s take on migration-based deployments: artifacts

The migration-based approach to database deployments is the DevOps-aligned method that helps teams automate and accelerate database change management by developing database code just application code..

Liquibase takes the migration method a step further by embracing the artifact-based approach.

Artifact-based deployments are a kind of migration-based deployment that packages small, atomic, iterative changes into artifacts. These artifacts are committed to database version control before being reviewed, tested, and deployed.

These changes, or ChangeSets in Liquibase, migrate the database schema, implementing iterative changes in an engineering mindset. This approach breaks down database change SQL code into more minute components, each of which has its own metadata independent of the Changeset file itself. Liquibase is agnostic when it comes to how you author your changes, so you can write any way you want, just like your application code.

Since the artifact-based approach explicitly defines all changes, and artifacts have their own metadata, it enables granular traceability and the ability to update, reorder, and deploy changes quickly. Artifacts, or ChangeLogs in Liquibase, also improve collaboration, making it easier for teams to work on changes together without stepping on toes or breaking each other’s code.

Why is artifact-based deployment a better method?

Liquibase takes the artifact-based approach because it treats database change as a fluid, collaborative, properly reviewed, and tested pipeline rather than a more forceful change directive whose consequences aren’t entirely known. Because Liquibase treats a ChangeSet as a collection of smaller changes that can all be individually reviewed and tested, a ChangeSet can be fixed and optimized before deployment without derailing the rest of the ChangeLog artifact. Liquibase helps teams match the pace of the application development pipeline and align on smaller, more frequent deployments.

In classic DevOps thinking, this innovative artifact-based approach uses smaller-scale changes as part of one whole change request, so you don’t just deploy and then succeed or fail entirely, without detail or context. Instead of having to rename files as you might in Flyway, Liquibase’s artifact deployments make it easy to move changes around and collaborate across teams.

The metadata within changesets includes Labels and Contexts, which give granular information about each element of the update, helping make the changeset artifact more than just a SQL change script committed to source control. Instead, it packages a contextualized, collaborative, observable asset that can be promoted and monitored throughout the pipeline. This detailed artifact metadata makes it easier to use advanced capabilities, including:

Targeted rollbacks
Automatic validation
Greater and more granular control and governance
Workflow analytics and observability

Liquibase helps teams match the pace of the application development pipeline and align on smaller, more frequent deployments

Teams looking for a complete, powerful database DevOps solution – with more than just the ability to automate a simple deployment – look to Liquibase.

State-based capabilities in Liquibase

Liquibase uses artifact migration-based deployments for its core change management automation features, However, as alluded to earlier, state-based methods do have their place. State can still be used, when appropriate, by an individual contributor to derive the changes, but never as a sole tool to deliver the changes.

Liquibase uses state comparisons to understand differences in database state through diff or drift commands. Liquibase Pro’s Drift Reports give a detailed analysis of differences, and drift detection automatically does state-to-state comparisons to alert teams of any unwanted or malicious changes.

Liquibase’s advanced DevOps capabilities

Liquibase Pro suits the needs of high-performing teams with advanced features for:

Automation
Collaboration
Standardization
Governance
Compliance
Security
Observability

…and more.

In comparison to Flyway Enterprise, users find Liquibase Pro can better meet the needs of teams and pipelines that strive for speed, integrity, and continuous optimization. Among a comprehensive database DevOps toolkit, class-leading features include:

Flows

For consistency in every deployment and the confidence that best practices are ingrained in every update, Liquibase Flows give teams the power to standardize their expertly orchestrated change workflows into redeployable Flow files. Flows are a unique feature to Liquibase — Flyway does not offer a way to orchestrate consistent deployments across teams and projects.

Quality Checks

Liquibase Quality Checks enable teams to customize rules and policies for on-demand execution or within the automated change management workflow. When you want to protect compliance and security while giving developers the confidence to submit safe database code, it takes a more powerful governance capability.

Compared to Flyway’s similar offering, Liquibase Quality Checks offer even stronger, more granular control across more types of databases.

Structured Logging

Every step in the Liquibase change management process is meticulously and automatically logged as it makes its way through automated checkpoints. If those logs aren’t actionable, though, they’re just taking up space. Liquibase transforms log data into Structured Logs, which organize them into machine-readable format that plays nice with DevOps monitoring dashboards.

Structured Logging enables rich and informative database observability with pipeline analytics and change operation monitoring. These metrics and reports enable insights for continuous process optimization as well as easier, more helpful analysis, troubleshooting, and auditing.

Targeted Rollbacks

No matter the severity of the problems at hand, executing a database rollback shouldn’t be a complex or stressful process. With Liquibase, every database change script is packaged with a rollback script, so it’s easy to roll back all changes or cherry-pick specific changes with a Targeted Rollback. While Flyway has its own database rollback capabilities, it takes a bit more configuration than the out-of-the-box solutions Liquibase offers.

These benefits alone give compelling reasons to switch to Liquibase. Teams also consider which databases integrate with Liquibase today, tomorrow, and years into the future.

Stronger support for more databases

In support of the varied and innovative landscape of modern data stores, Liquibase supports 60 different databases and a commitment to a steady flow of even more. Explore the index of supported databases, and you’re likely to find the ones your teams use today, plus the innovative new technologies that can bring more value to your organization.

Liquibase’s database integrations go deeper, for more advanced integration and robust capabilities that maximizes the unique values of each type of structure.