Want to deploy your JVM, Node.js and Go apps effortlessly to AWS? Try our service Boxfuse


Flyway updates the database from one version to the next using migrations.

Migrations can either be versioned or repeatable. Versioned migrations have a unique version and are applied exactly once. Repeatable migrations do not have a version. Instead they are (re-)applied every time their checksum changes.

Within a single migration run, repeatable migrations are always applied last, after all pending versioned migrations have been executed. Repeatable migrations are applied in the order of their description.

Both versioned and repeatable migrations can be written either in sql or in java and can consist of multiple statements.

Within a single migration, all statements are run within a single transaction.

Metadata table

To keep track of which migrations have already been applied when and by whom, Flyway adds a special bookkeeping table to your schema. This metadata table also tracks migration checksums and whether or not the migrations were successful.

Read more about this in our getting started guide on how Flyway works.

Migration States

Migrations are either resolved or applied. Resolved migrations have been detected by Flyway's filesystem and classpath scanner. Initially they are pending. Once they are executed against the database, they become applied.

All statements of a migration are run within a single transaction.

  • When the migration succeeds it is marked as success in Flyway's metadata table.
  • When the migration fails and the database supports DDL transactions, the migration is rolled back and nothing is recorded in the metadata table.
  • When the migration fails and the database doesn't supports DDL transactions, the migration is marked as failed in the metadata table, indicating manual database cleanup may be required.

Repeatable migrations whose checksum has changed since they are last applied are outdated until they are executed again.

When Flyway discovers an applied versioned migration with a version that is higher than the highest known version (this happens typically when a newer version of the software has migrated that schema), that migration is marked as future.

Versioned migrations