コンテンツへスキップ
LatchkeyLatchkey home

Alembic vs Flyway: データベースマイグレーションの比較

AlembicはPython/SQLAlchemy向けの自動生成機能を備えたマイグレーションツールで、FlywayはJVMやポリグロット環境で広く使われる言語非依存のSQLバージョン管理型マイグレーションrunnerです。

AlembicはSQLAlchemyと密接に統合され、モデルのdiffからマイグレーションを自動生成でき、Pythonプロジェクトの標準です。Flywayはバージョン管理されたSQL(および任意でJava)のマイグレーションを順に実行し、言語非依存で、そのシンプルで再現可能な適用モデルからJavaやポリグロットのチームで人気があります。

AlembicFlyway
エコシステムPython / SQLAlchemy言語非依存(JVM由来)
マイグレーション形式Pythonスクリプトバージョン管理されたSQL(+ Java)
自動生成あり(モデルから)なし(SQLを記述)
適用モデルリビジョングラフ順序付きバージョン
最適な用途Pythonアプリポリグロット / JVM、SQLファースト

CIでは

どちらもCIでデータベースに対してマイグレーションを適用します - Alembicはそのupgradeコマンドで、Flywayはflyway migrateで。AlembicはPython pipelineに適し、モデルをdiffできます。FlywayはCLIまたはコンテナとしてあらゆるpipelineにきれいに組み込めます。使い捨てのDBサービスに対してマイグレーションを実行し、すべてのPRで検証しましょう。

高速化する

依存関係をcache(またはFlywayのイメージをpull)し、使い捨てのDBに対してマイグレーションします。どちらもCI runnerで動作し、高速なmanaged runnerはインストールとマイグレーション適用を短縮します。

Decide with your own numbers, not a feature table

Feature comparisons age badly and rarely decide anything, because both tools in a mature category can do the job. What differs is how each behaves on your repository, and that takes one afternoon to measure.

Terminal
# time a cold install with each candidate, cache cleared
hyperfine --prepare "rm -rf node_modules" --warmup 1 \
  "<tool-a> install" "<tool-b> install"

# and the thing CI actually pays for: a cold run with no local cache
docker run --rm -v "$(pwd):/w" -w /w node:22 sh -c "<tool> install"

What actually changes when you switch

  • Lockfile format. A switch is a one-way door for anyone still on the old tool until everyone migrates, so plan it as a single coordinated change.
  • Resolution strictness. Tools differ on whether an undeclared transitive import works, and the stricter one will surface latent bugs as new failures.
  • CI cache configuration. The cache path and key differ per tool; carrying over the old ones silently disables caching.
  • Everyone on the team and every runner must move together. Pin the version so they cannot drift.

結論

自動生成マイグレーションを求めるPython/SQLAlchemyプロジェクト: Alembic。言語非依存でSQLバージョン管理型のマイグレーションを求めるポリグロットまたはJVMチーム: Flyway。エコシステムと、コードと生のSQLのどちらのマイグレーションを好むかで選びましょう。

よくある質問

Alembic vs Flyway: Database Migrations Compared?
Alembic integrates tightly with SQLAlchemy, can autogenerate migrations from model diffs, and is the standard for Python projects. Flyway runs versioned SQL (and optionally Java) migrations in order, is language-agnostic, and is popular in Java and polyglot teams for its simple, repeatable apply model.
In CI?
Both apply migrations against a database in CI - Alembic via its upgrade command, Flyway via flyway migrate. Alembic fits Python pipelines and can diff models; Flyway drops cleanly into any pipeline as a CLI or container. Run migrations against a disposable DB service to validate them on every PR.
Speed it up?
Cache dependencies (or pull the Flyway image) and migrate against a throwaway DB. Both run on CI runners; faster managed runners shorten install and migration apply.
Which should I choose?
Python/SQLAlchemy project wanting autogenerated migrations: Alembic. Polyglot or JVM team wanting language-agnostic, SQL-versioned migrations: Flyway. Choose by ecosystem and whether you prefer code or raw SQL migrations.

関連ガイド