Liquibase vs Alembic

Quick verdict

Liquibase is a database change management tool from Liquibase Inc. You write changesets, each with an id and author, in a changelog file in SQL, XML, YAML or JSON, and Liquibase records deployed changesets in its DATABASECHANGELOG table. It runs on Java (17 or later from version 5.0) from the command line, Docker, Maven, Gradle or Spring Boot. Liquibase Community 5.0.4 (20 August 2026) is the latest release on GitHub; the commercial edition is Liquibase Secure.

Alembic is "a database migrations tool written by the author of SQLAlchemy", in the words of its PyPI page. Migrations are Python files called revisions, each with an upgrade() and a downgrade() function that call operations such as op.create_table(). Alembic records the current revision in an alembic_version table. Version 1.20.0 was released on 11 September 2026; it requires Python 3.10 or later and is MIT licensed.

Both tools apply the same kinds of DDL commands; the difference is who writes the change definitions, in which language, and how tightly they are tied to the application code. For a comparison with a SQL-first tool, see Flyway vs Alembic.

Side by side

Key differences

Changelogs versus Python revisions

A Liquibase change is data, not code. This YAML changeset is based on the createTable example in the Liquibase documentation:

# Liquibase YAML changelog
databaseChangeLog:
-  changeSet:
    id:  createTable-example
    author:  liquibase-docs
    changes:
    -  createTable:
        tableName:  person
        columns:
        -  column:
            name:  address
            type:  varchar(255)

An Alembic change is a Python module. This is the revision from the Alembic tutorial, after the developer filled in the generated template:

# Alembic revision (Python), e.g. alembic/versions/1975ea83b712_create_account_table.py
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')

Because Alembic revisions are Python, you can use loops, conditionals and the SQLAlchemy expression language, and data migrations can reuse application code. Because Liquibase changesets are declarative, they can be read and reviewed by people who do not write Python, and the same XML, YAML or JSON change can be deployed to different engines. In our view this is the deciding question: is the schema owned by one Python application, or shared?

Autogenerate versus diff: generating migrations and their limits

Alembic's alembic revision --autogenerate compares your SQLAlchemy MetaData with the live database and writes a candidate revision. The Alembic documentation lists what it detects: tables and columns added or removed, nullability changes, basic changes to indexes and explicitly named unique constraints, and basic foreign key changes. Column type comparison is controlled by the compare_type setting and reliably detects major changes, such as Numeric to String, and server default comparison must be switched on with compare_server_default. The documentation is explicit about what autogenerate cannot detect: table and column renames (they appear as a drop and an add), anonymous (unnamed) constraints, some special types such as Enum on backends that do not support it, standalone sequences, and some constraint types such as PRIMARY KEY and EXCLUDE. It says autogenerate "is not intended to be perfect" and that you must review and correct the candidate migrations.

Liquibase does not read application models. Its Community edition offers diff, which reports differences between two databases, diff-changelog, which writes a changelog of changesets to reconcile them, and generate-changelog, which captures the current state of a database as a changelog, typically when adopting Liquibase on an existing system. The usual workflow is to write changesets by hand and use the diff commands as a check or a starting point.

The rename problem deserves a specific warning: if Alembic autogenerate sees a renamed column as a dropped column plus a new one, applying that revision unchanged would lose the column's data. Replace the generated drop and add with op.alter_column(..., new_column_name=...) before you run it.

Rollback and branching

Every Alembic revision has a downgrade() function, and alembic downgrade -1 or alembic downgrade <revision> runs them in reverse. Rollback is free and only as good as the downgrade code. Alembic treats revisions as a directed acyclic graph: when two developers create revisions from the same parent, you get two heads, and alembic merge creates a merge revision that joins them. Alembic can also write SQL instead of running it (offline mode, with --sql), so a DBA can review or apply the script.

Liquibase Community includes rollback to a tag, rollback-count and rollback-to-date, each with a -sql preview. Many modelled change types have automatic rollback; formatted SQL changesets need explicit -- rollback statements. Rolling back a single changeset out of order (rollback-one-changeset) or a single deployment (rollback-one-update) requires Liquibase Secure. Liquibase's ordering is the order of changesets in the changelog rather than a revision graph, and it offers contexts, labels and preconditions to control which changesets run where.

Databases and SQLite

Alembic supports the databases SQLAlchemy supports. SQLAlchemy includes dialects for PostgreSQL, MySQL and MariaDB, SQLite, Oracle and Microsoft SQL Server, and the project lists external dialects for others such as Snowflake, BigQuery, Redshift, Databricks and CockroachDB, each needing a DBAPI driver. SQLite gets special handling: because SQLite has limited ALTER TABLE support, Alembic offers "batch" migrations that create a new table with the desired structure, copy the data with INSERT ... SELECT, drop the old table and rename the new one. For the engine choice itself, see SQLite vs PostgreSQL.

Liquibase lists support for more than 65 databases, including relational engines, cloud data platforms such as Snowflake, BigQuery and Databricks, and NoSQL platforms such as MongoDB and Cassandra, many through extensions. From version 5.0, drivers and extensions are installed with the built-in package manager (liquibase lpm) rather than bundled.

Licence and commercial support

Alembic is MIT licensed and maintained in the SQLAlchemy organisation on GitHub. There is no paid edition.

Liquibase Community moved to the Functional Source License (FSL-1.1-ALv2) with version 5.0 on 30 September 2025. Liquibase says you can still use it in production and modify it, but third parties may not commercialise it in a way that competes with Liquibase; each release converts to Apache 2.0 after two years, and 4.x releases stay Apache 2.0. FSL is not an OSI-approved open source licence. Liquibase Secure adds drift detection, policy checks, targeted rollback, flow files, compliance reporting, secrets-manager integration and SLA-backed support.

Pricing and licensing

Alembic is free and open source under the MIT licence. There is no commercial edition.

Liquibase Community is free to use under FSL-1.1-ALv2. Liquibase Secure is sold in Starter, Team, Business and Enterprise plans; no prices were published on liquibase.com/pricing in October 2026, every plan requires a Professional Services package, and Starter is limited to companies with under USD 1 billion in annual revenue.

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 plain SQL files applied in order with minimal tooling: see Flyway vs Liquibase and Flyway vs Alembic.
• Your application is TypeScript: use your ORM's migration tool; see Prisma vs Drizzle ORM.
• You use Django rather than SQLAlchemy: Django has its own migrations framework built into the ORM, so Alembic does not apply.

Final recommendation

Frequently asked questions

Sources

• Alembic documentation
• Alembic: Auto generating migrations
• Alembic: Tutorial
• Alembic: Branches
• Alembic: Batch migrations for SQLite
• Alembic on PyPI (version, licence)
• SQLAlchemy: Dialects
• Liquibase: Community licence moves to FSL
• Liquibase Community 5.0 release notes
• Liquibase: Rollback commands
• Liquibase: diff-changelog
• Liquibase pricing
• Liquibase releases (GitHub)

Checked October 2026.

How we research comparisons: our editorial method.