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

> スキーマ移行のためのAlembic vs Flyway: Python/SQLAlchemyネイティブな自動生成 vs 言語非依存のSQLバージョン管理型マイグレーション。あなたのCI pipelineにはどちらが合うか?

Source: https://latchkey.dev/ja/learn/tool-comparisons/alembic-vs-flyway  
Updated: 2026-06-26

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

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

## Comparison

|  | Alembic | Flyway |
| --- | --- | --- |
| エコシステム | 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"
```

> Measure the cold path. Warm local benchmarks favour whichever tool you already have cached, which is exactly the condition a CI runner never has.

## 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のどちらのマイグレーションを好むかで選びましょう。

## FAQ

### 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.

---

Latchkey runs CI/CD that repairs its own failures. Agent entry points: https://latchkey.dev/agent.txt, https://latchkey.dev/openapi.json, https://latchkey.dev/llms.txt