Liquibase, Flyway or a Visual Schema Compare

Migrations • 12-Aug-2026

Key takeaways

Flyway manages schema migrations using a linear versioning system of explicitly named SQL scripts.

Liquibase orchestrates changes across 65+ databases using flexible XML, YAML, JSON, or SQL master changelogs.

Flyway discontinued its Teams tier in 2025, restricting automated rollbacks to its Enterprise license.

A visual schema compare replaces hand-written scripts by storing the database structure as a plain XML file that diffs in Git.

Comparing the local offline model against a live database generates precise migration scripts automatically.

Is Flyway still used?

Flyway remains a primary choice for database change management in modern DevOps environments. Backend teams adopt Flyway to automate schema migrations directly within CI/CD pipelines alongside application code deployments.

The platform relies on a linear versioning model that enforces strict SQL file naming conventions. Every migration file uses explicit prefixes to govern execution behavior during deployment.

V: Versioned migrations that execute sequentially once and update the schema state.
U: Undo migrations that revert specific versioned changes.
R: Repeatable migrations that re-execute whenever their checksum changes, ideal for views and stored procedures.

Redgate acquired Flyway to integrate database migrations into enterprise DevOps workflows. Today, 92% of the Fortune 100 rely on Redgate software to manage critical database infrastructure and automate deployment pipelines[1].

By tying schema migrations to versioned SQL scripts, Flyway enables software engineers to track database modifications inside Git repositories. However, managing sequential version numbers across multiple feature branches often creates deployment collisions in active engineering teams.

What is the purpose of Liquibase?

Liquibase provides automated database change governance across complex multi-database environments. It acts as an abstraction layer between application code and database platforms, ensuring consistent deployment policies across pipelines.

Central to Liquibase is the master changelog concept. Engineers declare database modifications in changelog files rather than writing engine-specific DDL scripts. Liquibase evaluates these changelogs and executes the appropriate SQL statements against the target instance.

Format	Abstraction Level	Target Audience
XML	Database-agnostic tags	Enterprise teams managing heterogeneous databases
YAML	Structured declarative syntax	DevOps engineers configuring automated pipelines
JSON	Programmatic structured format	Cloud-native services and REST integration
SQL	Raw DDL with Liquibase comments	Developers writing native database scripts

Liquibase supports 65+ databases, allowing organizations to standardize migration workflows across relational systems and document stores[2]. Enterprise teams achieve up to 120x faster deployments while enforcing policy checks and audit controls across release pipelines[2].

Abstracting SQL into structured formats allows Liquibase to deploy identical change sets across different target engines, such as PostgreSQL, Oracle, and Snowflake, without rewriting migration logic.

The Liquibase and Flyway approach

Liquibase and Flyway share an evolutionary database design philosophy. Both tools treat database schemas as living code bases that evolve incrementally alongside backend application code.

Both platforms are Java-based systems that integrate with build tools like Maven and Gradle or run as standalone command-line utilities. Each one tracks applied migrations by creating dedicated tracking tables inside the target database: Flyway adds a schema history table that records the version, description, type and filename of each migration, along with a checksum and the date, duration and user that ran it[3], while Liquibase creates DATABASECHANGELOG automatically if it does not already exist[4], alongside DATABASECHANGELOGLOCK[5].

Operational Metric	Flyway Workflow	Liquibase Workflow
Schema Tracking Table	flyway_schema_history	databasechangelog
Change Ordering	Linear filename version number (e.g., V1__init.sql)	Explicit order defined in master changelog file
Migration Definition	Raw SQL scripts or Java code	XML, YAML, JSON, or formatted SQL
Pipeline Interlinking	Integrates with schema migration tools in CI/CD	Integrates via CLI, Java API, or native CI plugins

Flyway's schema history table acts as the bookkeeping record of every versioned migration applied to the database, recalculating each file's checksum on every run and raising an error if a previously applied file has changed[3]. Liquibase splits the job in two: DATABASECHANGELOG records each changeset as a row identified by id, author and filename, together with its execution type, checksum and timestamp, so only changesets that have not run are deployed[4], while DATABASECHANGELOGLOCK allows only a single instance of Liquibase to run against the database at a time[5].

While both tools eliminate manual database patching, they force developers to write and manage individual migration scripts for every minor schema iteration.

Is Flyway better than Liquibase?

Deciding whether Flyway is better than Liquibase depends on team architecture, database complexity, and rollback requirements. Flyway favors simplicity and developer accessibility, whereas Liquibase emphasizes structural abstraction and governance.

Developer workflows differ significantly when handling rollbacks and environment-specific deployments. Liquibase can reverse deployed changes sequentially back to a tagged state, and companion commands roll back to a given date and time or a set number of changesets[6][7]. Preconditions control the execution of an update based on the state of the database[8], while context and label filters decide which environments a changeset reaches[9].

Rollback Execution: Liquibase rolls back deployed changes sequentially until it reaches a tag row in DATABASECHANGELOG, with separate commands for rolling back to a date and time or a number of changesets[6], whereas Flyway relies on undo migrations, optional scripts a developer writes to undo the versioned migration with the same version[10].
Schema Drift Detection: Flyway's check -drift command checks a target environment for drift to ensure it is still in the expected state for running deployments, and the deployment can be aborted if drift is detected[11].
Contextual Rules: Liquibase preconditions control whether an update runs based on the state of the database[8], and context and label filters select which changesets deploy to which environment[9].

Flyway provides a lightweight CLI that developers can learn quickly, making it popular for single-database Java applications. Liquibase requires a steeper learning curve due to its XML and YAML abstraction tags, but offers greater flexibility for multi-database enterprise architectures.

Is Liquibase free to use?

Both Liquibase and Flyway offer open-source tiers alongside commercial subscriptions, but their licensing models diverge at the enterprise level.

Liquibase provides Liquibase Open Source, a free community product that includes core changelog execution, database tracking, and basic migration capabilities. Organizations requiring advanced governance, policy enforcement, and AI remediation upgrade to Liquibase Secure or Liquibase Pro.

Feature Axis	Liquibase Open Source / Secure	Flyway Community / Enterprise
Free Core Tier	Liquibase Open Source (Free, full core CLI)	Flyway Community (Free, Apache 2.0 / basic capabilities)
Commercial Tiers	Liquibase Pro and Liquibase Secure	Flyway Enterprise
Change Definition	XML, YAML, JSON or SQL changelogs	SQL or Java migration scripts
Rollback Capability	rollback is one of the core Liquibase commands	Undo migrations are an edition-gated feature rather than part of the free core
Drift Checking	diff and snapshot commands	check -drift compares a target environment against a snapshot and can abort deployment on drift

Flyway's commercial line-up now centres on the free Community tier and the paid tiers, and several capabilities backend teams assume are standard sit on the paid side. Undo migrations, the optional scripts that undo the versioned migration with the same version, are documented as an edition-gated feature rather than part of the free core[10], and drift checking runs through the check -drift command, which compares a target environment against a snapshot and can abort the deployment when drift appears[11].

Teams evaluating open-source options must determine whether free-tier constraints align with their long-term security and rollback requirements.

What is the alternative to Liquibase?

An alternative to code-only migration libraries is Visual Schema Compare. Instead of manually writing sequential SQL scripts or complex XML changelogs, backend developers manage database structure visually using a dedicated architecture file.

A visual modeling tool stores the schema in a dedicated project file that holds table structures, foreign keys, and indexes in a plain XML format. Because the file contains only structural DDL definitions without production data, developers commit it directly to Git repositories.

Visual Schema Modeling: Build tables, edit data types, and establish foreign keys inside an interactive ER diagram without writing raw DDL.
Git Version Control: Review schema diffs using native Git tools, tracking every column or table addition across pull requests.
Automated DDL Generation: Generate migration SQL automatically by comparing the design model file against target live databases.

Visual modeling shifts schema management from handwriting migration code to declaring desired state inside a versioned design file. This eliminates script ordering mistakes and ensures complete visibility across complex database layouts.

The situation a visual schema compare solves

Database schemas drift constantly during rapid application development. Developers add columns locally, hotfix staging environments, or miss running sequential migration scripts. Visual schema comparison resolves schema drift by comparing actual database states against target design files.

Consider a real-world worked diff scenario. A developer adds a last_login timestamp column and an index to the users table inside their local design model. When schema synchronization opens, the tool compares the local design model against the target staging database.

The visual comparison window highlights missing columns, mismatched data types, and missing constraints side by side. Developers review each difference and generate precise, executable migration scripts to bring the live database into sync without touching unaffected tables.

We provide DbSchema to give backend teams complete visual control over database models, migrations, and documentation. A free Community Edition covers visual schema modeling, while the paid Pro Edition adds advanced schema synchronization, offline schema design, and HTML5 documentation. Download it and open the model against your own database to compare schemas and deploy changes safely.

FAQ

What is the difference between Flyway and Liquibase?

Flyway relies on a strict, linear versioning system where changes are written as explicitly named SQL files (using V, U, and R prefixes). Liquibase uses a master changelog approach, allowing developers to define schema changes in database-agnostic formats like XML, YAML, or JSON alongside standard SQL.

Are Liquibase and Flyway free to use?

Both tools offer open-source community editions for basic migrations. Liquibase provides advanced governance features in its paid tiers, while Flyway offers a free Community edition and a paid Enterprise edition, having discontinued its intermediate Teams tier in 2025.

How does Liquibase rollback a change?

Liquibase supports native rollback commands to undo specific migrations automatically. In contrast, Flyway requires developers to write explicit rollback scripts manually, and this functionality is restricted to its Enterprise edition.

What is a visual schema compare?

A visual schema compare is a tool that connects to a live database and compares its current structure against an offline design model. It identifies drift - like a newly added column or a missing table - and allows you to review the differences visually before deploying changes.