Flyway wraps the execution of each migration script in a single transaction and applies them in order. For example, if I have 3 pending migrations on my target, calling flyway migrate looks like:

- Execute V001
  If success, commit and continue; else rollback (if possible) and stop - do not process any further pending migrations
- Execute V002
  If success, commit and continue; else rollback (if possible) and stop - do not process any further pending migrations
- Execute V003
  If success, commit and continue; else rollback (if possible) and stop - do not process any further pending migrations

Alternatively, for certain databases, for each migrate, you can configure Flyway to wrap the execution of all pending migrations in a single transaction by setting the group property to true. This would look like:

Begin a transaction
  Execute V001
  Execute V002
  Execute V003
End transaction
If there are errors at any point, rollback to the starting point and stop processing.

If Flyway detects that a specific statement cannot be run within a transaction due to technical limitations of your database, it won't run that migration within a transaction. Instead, it will be marked as non-transactional.

If the group property is set to true, then transactional and non-transactional statements cannot be mixed within a migration run. You can allow this by setting the mixed property to true. Note that this is only applicable for PostgreSQL, Aurora PostgreSQL, SQL Server and SQLite which all have statements that do not run at all within a transaction. This is not to be confused with implicit transactions, as they occur in MySQL or Oracle, where even though a DDL statement was run within a transaction, the database will issue an implicit commit before and after its execution.

Manual override

If necessary, you can manually determine whether or not to execute a migration in a transaction. This is useful for databases like PostgreSQL and SQL Server where certain statements can only execute outside a transaction.

For Java migrations, the JavaMigration interface has a method canExecuteInTransaction. This determines whether the execution should take place inside a transaction. You can rely on BaseJavaMigration's default behavior to return true or override canExecuteInTransaction to execute certain migrations outside a transaction by returning false.

For SQL migrations, you can specify the script configuration property executeInTransaction. See Script config.

Important Note

If your database cleanly supports DDL statements within a transaction, failed migrations will always be rolled back (unless they were marked as non-transactional).

If on the other hand your database does NOT cleanly supports DDL statements within a transaction (by for example issuing an implicit commit before and after every DDL statement), Flyway won't be able to perform a clean rollback in case of failure and will instead mark the migration as failed, indicating that some manual cleanup may be required. You may also need to run repair to remove the failed migration entry from the schema history table.