# Alembic vs Flyway: migrações de banco de dados comparadas

> Alembic vs Flyway para migrações de schema: autogeração nativa de Python/SQLAlchemy vs migrações versionadas em SQL e agnósticas de linguagem. Qual se encaixa no seu pipeline de CI?

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

O Alembic é a ferramenta de migração de Python/SQLAlchemy com autogeração; o Flyway é um runner de migração agnóstico de linguagem, versionado em SQL, amplamente usado em ambientes JVM e poliglotas.

O Alembic se integra fortemente ao SQLAlchemy, pode autogerar migrações a partir de diffs de modelos e é o padrão para projetos Python. O Flyway executa migrações versionadas em SQL (e opcionalmente Java) em ordem, é agnóstico de linguagem e é popular em times Java e poliglotas por seu modelo de aplicação simples e repetível.

## Comparison

|  | Alembic | Flyway |
| --- | --- | --- |
| Ecossistema | Python / SQLAlchemy | Agnóstico de linguagem (raízes JVM) |
| Formato de migração | Scripts Python | SQL versionado (+ Java) |
| Autogeração | Sim (a partir dos modelos) | Não (escreva SQL) |
| Modelo de aplicação | Grafo de revisões | Versões ordenadas |
| Melhor para | Apps Python | Poliglota / JVM, SQL-first |

## Em CI

Ambos aplicam migrações contra um banco de dados em CI - o Alembic via seu comando upgrade, o Flyway via flyway migrate. O Alembic se encaixa em pipelines Python e pode comparar modelos; o Flyway entra de forma limpa em qualquer pipeline como CLI ou container. Execute as migrações contra um serviço de DB descartável para validá-las em cada PR.

## Acelere

Faça cache das dependências (ou baixe a imagem do Flyway) e migre contra um DB descartável. Ambos rodam em CI runners; managed runners mais rápidos encurtam a instalação e a aplicação das migrações.

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

## O veredito

Projeto Python/SQLAlchemy que quer migrações autogeradas: Alembic. Time poliglota ou JVM que quer migrações agnósticas de linguagem e versionadas em SQL: Flyway. Escolha pelo ecossistema e por preferir migrações em código ou em SQL puro.

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