Flyway vs Alembic

Quick verdict

Flyway, owned by Redgate, applies versioned migration scripts, usually plain SQL files named like V1__Create_person_table.sql, in version order and records them in a schema history table. Flyway OSS is built from Apache 2.0 licensed code; Flyway Community is a free edition with some proprietary additions and the Flyway Desktop GUI; Flyway Enterprise is paid. It runs on Java, from a command-line tool for Windows, macOS and Linux, Docker, Maven, Gradle or the Java API. The latest Flyway Engine release is 13.9.0 (1 October 2026).

Alembic is the migration tool for SQLAlchemy, written by SQLAlchemy's author. Migrations are Python revision files with upgrade() and downgrade() functions, and the current revision is stored in an alembic_version table. Alembic 1.20.0 was released on 11 September 2026, requires Python 3.10 or later and is MIT licensed.

This page is about the SQL-first versus Python-first choice. If you are weighing a language-neutral changelog tool against Alembic instead, see Liquibase vs Alembic; for the two Java tools, see Flyway vs Liquibase.

Side by side

Key differences

SQL files versus Python revisions: the same table both ways

A Flyway migration is the SQL that will run, here the example from Flyway's getting-started material:

-- db/migration/V1__Create_person_table.sql  (Flyway, generic SQL)
create table PERSON (
    ID int not null,
    NAME varchar(100) not null
);

An Alembic migration describes the change in Python, and SQLAlchemy renders the SQL for the connected dialect. This is the revision from the Alembic tutorial:

# alembic/versions/1975ea83b712_create_account_table.py  (Alembic, Python)
revision = '1975ea83b712'
down_revision = None
branch_labels = None

from alembic import op
import sqlalchemy as sa

def upgrade():
    op.create_table(
        'account',
        sa.Column('id', sa.Integer, primary_key=True),
        sa.Column('name', sa.String(50), nullable=False),
        sa.Column('description', sa.Unicode(200)),
    )

def downgrade():
    op.drop_table('account')

With Flyway you write dialect-specific SQL and get full control, including vendor features that an abstraction layer may not model. With Alembic the same revision can target several SQLAlchemy dialects, and you can drop to raw SQL with op.execute() when you need to. In our view, teams with strong SQL reviewers or DBAs tend to prefer Flyway's directness, while Python teams prefer keeping migrations next to their models in the same language. For the underlying statements, see DDL commands.

Autogenerate: what Alembic drafts, and what it misses

Flyway Community does not generate migrations: you write each file. Redgate lists script generation from its comparison engine as a Flyway Enterprise feature.

Alembic's alembic revision --autogenerate -m "..." compares your SQLAlchemy model metadata with the database and writes a candidate revision. According to the Alembic documentation it detects added and removed tables and columns, nullability changes, basic index and explicitly named unique constraint changes, and basic foreign key changes; type and server default comparison are controlled by the compare_type and compare_server_default settings. It cannot detect table or column renames (they appear as a drop plus an add), anonymous constraints, some special types such as Enum on backends that lack it, standalone sequences, or some constraint types such as PRIMARY KEY and EXCLUDE. The documentation says autogenerate "is not intended to be perfect" and that candidate migrations must be reviewed and corrected.

Practically, Alembic saves typing for routine changes and leaves you responsible for renames, data migrations and anything the models do not express. Flyway leaves you responsible for everything, which some teams prefer because nothing is implied.

Rollback: free downgrades versus paid undo

Every Alembic revision has a downgrade(), and alembic downgrade -1 steps back one revision. This costs nothing, but a downgrade is only as good as its code, and it cannot restore data that the upgrade dropped.

In Flyway, rollback means an undo migration with the same version as the migration it reverses, run with flyway undo:

-- db/migration/U1__Create_person_table.sql  (Flyway undo migration, paid editions)
drop table PERSON;

Redgate's documentation marks undo as a Teams edition feature and says the undo command needs a Teams or Enterprise licence key; Redgate's current editions page lists only Community and Enterprise. Redgate itself recommends backward-compatible changes and a tested backup and restore strategy rather than relying on undo alone, because undo assumes the migration fully succeeded and handles destructive changes poorly. Without a paid licence, Flyway users roll back by writing a new forward migration.

Team workflow, branching and review

Flyway orders migrations by version number. Two developers who both create V5__... must resolve the clash, and by default Flyway expects migrations to be applied in order. Alembic links each revision to its parent through down_revision, so parallel work produces two heads; alembic merge writes a merge revision that joins them into one history.

For review and controlled environments, Flyway's files are already SQL. Alembic's offline mode (alembic upgrade head --sql) renders the revisions as a SQL script that a DBA can review or apply, which suits organisations where application developers cannot run migrations against production.

Databases and SQLite

Flyway's core commands work on more than 50 database systems, including PostgreSQL, MySQL, MariaDB, SQL Server, Oracle, SQLite and Snowflake, according to Redgate. Alembic supports what SQLAlchemy supports: built-in dialects for PostgreSQL, MySQL and MariaDB, SQLite, Oracle and SQL Server, and external dialects for others.

SQLite is a common case in Python projects. Its ALTER TABLE support is limited, and Alembic provides batch migrations that recreate the table with the new structure, copy the data, drop the old table and rename the new one. With Flyway you write that table rebuild in SQL yourself. If you are choosing the engine as well, see SQLite vs PostgreSQL.

Pricing and licensing

Alembic is free and open source under the MIT licence, with no paid edition.

Flyway OSS (Apache 2.0) and Flyway Community are free. Flyway Enterprise is paid, with a 28-day trial; Redgate's pricing page showed no list prices in October 2026, so a quote is needed. Redgate's licensing FAQ describes paid licences as per user.

Pricing checked on the vendors' official pages on 7 October 2026. Prices change; confirm before buying.

Where each one leads

Limitations

When to choose each

When neither is right

• You want rollback commands and database-independent changesets in a free, language-neutral tool: see Flyway vs Liquibase.
• Your project is TypeScript: compare the ORM migration tools in Prisma vs Drizzle ORM.
• You use Django: its built-in migrations framework is the natural choice, not Alembic.

Final recommendation

Frequently asked questions

Sources

• Redgate Flyway documentation
• Redgate: Flyway editions
• Flyway: Undo migrations
• Flyway: Feature summary by edition
• Flyway Engine release notes
• Flyway repository and licence (GitHub)
• Alembic: Tutorial
• Alembic: Auto generating migrations
• Alembic: Branches
• Alembic: Batch migrations for SQLite
• Alembic on PyPI (version, licence)
• SQLAlchemy: Dialects

Checked October 2026.

How we research comparisons: our editorial method.