Flyway and Liquibase are the established choices — Flyway if you want plain SQL files applied in order, Liquibase if you want a changelog format with rollback support built in. Atlas treats schema as declarative state and computes the diff. Prisma Migrate, Alembic, Django migrations and Rails migrations come with their frameworks and are the right answer if you are already there. The part no tool handles is the one that breaks production: a migration that is safe to run and unsafe to run while the old code is still deployed. Expand-and-contract is the pattern, and it is a process decision rather than a tool feature.
Choosing a migration tool is easy. Sequencing a schema change against a rolling deploy is what actually causes outages.
Two different jobs
Versioned migrations — an ordered list of changes, each applied once, recorded in a table. Flyway, Liquibase, Alembic, Rails and Django all work this way. It is predictable and it is what most teams should use.
Declarative schema — you describe the desired state and the tool computes the change. Atlas works this way, as do parts of Prisma. It is pleasant for development and needs care in production, because the computed diff is only as good as the tool's understanding of what is safe.
At a glance
| Tool | Model | Rollback | Best for |
|---|---|---|---|
| Flyway | Versioned, plain SQL | Manual (paid tiers add support) | Teams who want SQL and nothing else |
| Liquibase | Versioned, changelog format | Built in | Teams wanting rollback and multi-DB support |
| Atlas | Declarative + versioned | Computed | Schema-as-state workflows |
| Prisma Migrate | Versioned, from schema file | Limited | Existing Prisma projects |
| Alembic | Versioned, Python | Manual | SQLAlchemy projects |
| Rails / Django | Versioned, framework-native | Partial | Already in that framework |
Pricing shapes checked September 2026 — most have open-source cores with paid tiers; verify live.
The tools, briefly
Flyway does one thing: applies numbered SQL files in order and records what it applied. That is a feature. If your team is comfortable in SQL, there is very little to learn and very little to go wrong.
Liquibase adds a changelog abstraction, real rollback definitions and multi-database support. Worth it when you genuinely need rollback or target more than one database engine; extra machinery otherwise.
Atlas is the most interesting recent entry — declare the schema you want, let it plan the migration, with linting that flags destructive or blocking changes before they run. That linting is the part worth adopting even if you keep your current tool.
Framework-native tools (Prisma, Alembic, Rails, Django) are almost always the right choice inside their framework. Adding a second migration system beside a framework's own is a recipe for two sources of truth about the schema.
Got an idea? Build it now!
Just start with a simple prompt. No coding required — Greta.sh turns your idea into a working app in minutes.
The part that causes outages
A migration that is individually safe can still break production if it runs while the previous version of the application is live, which during a rolling deploy it always is. Dropping a column the old code still reads, renaming a column in one step, or adding a NOT NULL constraint before the new code populates it all fail this way.
The pattern is expand and contract, in three deploys rather than one. Expand: add the new column, keep the old one, write to both. Migrate: backfill, in batches, with the application running. Contract: once no deployed code reads the old column, drop it — a separate release, days later, not the same afternoon.
Three other things worth knowing before a large table: adding an index can lock writes unless your engine supports building it concurrently; a backfill in one statement can hold a lock long enough to time out every request; and "it ran fine on staging" means little when staging has a thousand rows and production has forty million.
If the app was generated
Generated applications have schemas and need the same discipline — the code that reads a column does not care how it was written. Plainly: Greta builds and deploys the app and is not a migration tool; use one of the above for versioned schema changes. What changes is that a schema change and the code change that depends on it are described together, so the expand-and-contract sequencing has to be stated deliberately rather than assumed. The data reconciliation plan covers verifying the result. Free tier is 30 credits a month (5 a day); $20/month after ($5 with the current welcome offer).
FAQ
What is the best database migration tool? Flyway for plain SQL, Liquibase when you need rollback or multiple engines, Atlas for declarative schemas with safety linting, and your framework's own tool if you have one.
Do I need rollback support? Less than you would think. Forward-only migration with expand-and-contract means you rarely need to reverse a change, because nothing destructive happened yet. Rollback matters most for changes that cannot be made non-destructive.
How do I add a NOT NULL column safely? Add it nullable, backfill in batches, then add the constraint once every row satisfies it. Doing it in one statement locks the table for the duration of the backfill.
Is it safe to run migrations automatically on deploy? For additive changes, generally yes. For anything destructive or locking, no — those should be separate, deliberate, and run when someone is watching.
