# Flyway: versioned database migrations for JVM builds and the CLI

> Flyway is an Apache-2.0 migration tool from Redgate that applies ordered SQL migrations across 50+ databases. This review covers how it works, where the README points for installation, and where it stops being the right choice.

**flyway/flyway** — Flyway by Redgate • Database Migrations Made Easy.

- Repository: https://github.com/flyway/flyway
- Website: https://flywaydb.org
- Stars: 10,113 · Forks: 1,631
- Language: Java
- License: Apache-2.0
- Published: 2026-09-21 · Updated: 2026-09-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/flyway-flyway

## What Flyway solves, and who ends up using it

Schema changes are the part of deployment that version control handles badly. Application code can be redeployed at will; a table that already holds rows cannot. Flyway's answer is to treat each schema change as a numbered file that runs once, in order, and is recorded in the database itself. The README frames the goal as evolving "your database schema easily and reliably across all your instances", which is the real constraint: the same migration set has to land identically on a developer laptop, a CI database, and production.

The intended users are teams that already keep SQL in the repository and want the database to move with the application. The README lists Maven and Gradle as supported build tools, so a Java service can run migrations as part of its build lifecycle. It also lists Windows, macOS, Linux, Docker and Java as supported platforms, which means the same migration files can be driven by a JVM library in a service or by a standalone command-line binary in a release pipeline. People who prefer to define schema changes in a programming language, or who want the tool to generate the diff between two live schemas, are not the audience here.

## Versioned SQL files, a schema history table, and a checksum

The mechanism is deliberately small. Migrations live in configured locations (the repository has a top-level flyway-locations module, and location configuration is part of the documented setup). Each file carries a version, and Flyway applies pending versions in order against the target database. What has already run is tracked in a schema history table inside that database, so the state of the schema and the state of the migration set are stored together.

That history table is also where integrity checking happens. Each applied migration is recorded with a checksum, and an edited file that has already run no longer matches. This is why the tool matters beyond convenience: it makes an accidental edit to a shipped migration visible instead of silent. The repository layout reflects the split between engine and reach: flyway-core holds the engine, flyway-database and flyway-plugins hold database support, flyway-commandline and flyway-command build the CLI, and flyway-docker packages it. The README also points to a separate flyway-community-db-support repository for additional dialects such as ClickHouse, DuckDB, TiDB and YugabyteDB, which tells you the core list and the community list are maintained in different places.

## Getting Flyway and running a first migration

The README does not inline install commands. It points to the Flyway documentation pages for downloading Flyway OSS, and to the Redgate website for the commercial editions, which the README explicitly says are not part of the open source project. The documentation link it gives is titled Getting started guides, so that is where the setup steps live. For Maven users, the badge links to the org.flywaydb:flyway-core artifact on Maven Central, so the library route is a normal dependency.

Because the README carries no command examples, treat the first run as something to confirm against the documentation rather than against this page. What the README does establish is the shape of the work: migrations are SQL files, they are applied in order, and the result is recorded in the database. The behaviour to verify on a disposable database is that a second run reports nothing left to apply instead of repeating the first. The repository layout also shows where the entry points sit: flyway-commandline builds the CLI, and flyway-maven-plugin and flyway-gradle-plugin are the build-tool integrations, which is what you configure in a JVM project.

## Repair exists; rollback is not in the documented surface

The most common expectation to correct is reversibility. Flyway's documented operations centre on migrating forward and on repair, which fixes the schema history table when it disagrees with reality, for example after a failed migration or a manually changed database. There is no documented undo command in the README, and the README does not document rollback at all. Teams that need to reverse a schema change have to write and run that change themselves, as a new forward migration or as an out-of-band script.

That is a real trade-off, not a gap in the README's prose. A tool that stores a checksum for every applied migration cannot also let you rewrite history without weakening the check. The consequence is operational: your recovery plan for a bad migration is a new migration, and your review process has to catch destructive statements before they run, because the tool's job is to apply what you wrote, not to judge it. The second limitation is dialect coverage. The README lists 50+ supported DBMS in the core project and a further set in the community repository, and those two lists have different maintainers. If your database sits in the community list, a dialect bug is fixed on that repository's schedule, not the main one's.

## How Flyway differs from Liquibase

Liquibase is the alternative most often weighed against Flyway, and the difference is where the schema definition lives. Flyway's unit of change is a versioned SQL file applied in order, with the database recording what ran. Liquibase's unit is a change set described in XML, YAML, JSON or SQL, with the tool holding a model of the change and a changelog that supports explicit rollback definitions. That model is why Liquibase can generate a rollback for some change types and why it can express a change portably across databases.

Flyway's approach gives you the SQL your database actually runs, which is easier to read and to tune, and it means no abstraction sits between the file and the server. Liquibase's approach gives you portability and a rollback story at the cost of an extra layer to learn. If your team already reviews SQL and runs one or two database engines, Flyway's smaller surface is the better fit. If you need the same changelog to target several engines with generated rollback, Liquibase is doing work Flyway leaves to you.

## Licence, editions and what upgrades cost you

The code is Apache-2.0, and the README carries the standard Apache text plus a trademark note: Flyway is a registered trademark of Boxfuse GmbH, owned by Red Gate Software Ltd. Apache-2.0 permits commercial use and modification; the trademark line is a separate matter from the code grant, and it is worth reading the LICENSE.txt and LICENSE.md files in the repository if you plan to use the name in a product. This is not legal advice.

The edition split is the practical cost centre. The README states that Redgate also develops Flyway Community and Flyway Enterprise, that these editions come with a GUI and additional capabilities, and that they are not part of the open source project. So the open source CLI and library are one product, and the commercial editions are another, with their own download pages and trials. Budget decisions should treat them as separate purchases rather than as an upgrade path inside the repository.

On maintenance, the repository is not archived and the last push was on 2026-09-15, with releases flyway-13.7.0 on 2026-09-15, flyway-13.6.0 on 2026-09-10 and flyway-13.5.0 on 2026-09-03. That release cadence is the upgrade cost to plan for: version numbers move quickly, and the release notes are published on the documentation site rather than in the repository README, so a pinning policy plus a read of those notes is the realistic process. Nothing in the README documents a compatibility guarantee between engine versions and existing schema history tables, so verify that on a copy before upgrading production.

## Conclusion

Adopt Flyway if you keep schema changes as ordered SQL files and want the same tool to run them from Maven, Gradle, or a shell on Windows, macOS, Linux, or Docker. Do not adopt it expecting a documented rollback command: the README and release notes cover migration and repair, not undo, so teams that need reversible schema changes must write their own down-migrations. Before committing, verify on a disposable database which of your target DBMS is in the core support list versus the separate flyway-community-db-support repository, because that distinction determines who fixes a dialect problem.

## FAQ

### What is Flyway used for?

Flyway applies versioned database migrations in order and records what has run in a schema history table inside the target database. The README describes it as a way to evolve your database schema easily and reliably across all your instances.

### Is Flyway free to use?

The open source project is licensed under Apache-2.0. Redgate also maintains Flyway Community and Flyway Enterprise editions with a GUI and additional capabilities, and the README notes those editions are not part of the open source project.

### How do I install the Flyway CLI?

The README does not inline install steps; it points to the Flyway documentation pages for downloading Flyway OSS, and to the Redgate website for the commercial editions. The documentation link it gives is titled Getting started guides.

### How do I use Flyway with PostgreSQL?

PostgreSQL is listed among the supported databases in the README. The README itself gives no configuration example, so the connection details and command syntax come from the reference documentation rather than this page.

### What does flyway repair do?

Repair is one of the documented operations and addresses a schema history table that disagrees with the actual database, for example after a failed migration. The README does not document a rollback command, so repair is not a substitute for writing a reversing migration.

## Sources

- [flyway/flyway on GitHub](https://github.com/flyway/flyway)
- [License: Apache-2.0](https://github.com/flyway/flyway/blob/main/LICENSE)
- [Project website](https://flywaydb.org)
- [README](https://github.com/flyway/flyway/blob/main/README.md)
- [Releases](https://github.com/flyway/flyway/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/flyway-flyway