Online Tool Store
· 6 min read
3 Database Migration Tools, Compared
Manesh Jayawardhana
CIO & Co-founder
The migration ran in staging, ran in production, and locked a table for four minutes at lunchtime. Or it ran fine and the rollback did not exist, because nobody writes the down migration when the up one works.
There are two separate problems here and they are usually conflated. Writing correct migration SQL — including the reverse, and in an order that does not lock a live table — is one. Applying migrations in the right sequence and tracking which have run is the other. Almost every well-known tool solves the second and leaves the first to you.
How to judge a migration tool
Does it track what has run? A schema table recording applied versions is the minimum. Without it you are guessing at state.
Up and down as separate files? Explicit reverse migrations are what make a rollback possible. Tools that treat down as optional produce codebases where it does not exist.
Which databases? Postgres and MySQL are universal. Anything beyond that narrows the field quickly.
Does it write the SQL, or run it? Most run it. Generating the statements — especially the safe ordering for a live table — is a different job.
The comparison
| Tool | Best for | Free tier | Watch out |
|---|---|---|---|
| golang-migrate | Breadth of database support | Free, open source, CLI and Go library | Runs migrations; doesn’t write them |
| Flyway Community | Plain-SQL versioning across 60+ platforms | Free community edition | Diff generation and governance are paid |
| Postgrator | Node projects wanting plain SQL scripts | Free, open source (MIT) | Four databases |
Facts checked August 2026; tools change their plans. Table covers only the 3 alternatives — our tool gets its own section below.
golang-migrate
The most widely applicable of the three. It reads migrations from a source and applies them in the correct order, working as both a CLI and a Go library, and it supports 25 or more databases — PostgreSQL, MySQL, SQLite, MongoDB, CockroachDB, Cloud Spanner and Redshift among them.
Its file convention enforces the good habit: every migration is a pair, ..._create_users_table.up.sql and .down.sql, so the reverse exists as a file whether or not you fill it in thoughtfully. Free and open source. It runs what you give it — the SQL inside those files is yours to write.
Flyway Community
The most established. Flyway has been versioning database schemas with plain SQL scripts since 2010, tracking which migrations have been applied and automating deployment across environments, with support for 60+ database platforms including SQL Server, Oracle, Snowflake, MongoDB and BigQuery.
The community edition is free and open source with a large contributor base. The commercial editions add the governance and pipeline features teams reach for at scale — and, notably, the schema comparison and diff-based script generation that would actually write migrations for you. In the free edition, the SQL is still yours.
Postgrator
The lightest. A Node.js library that applies plain SQL scripts named [version].[action].[description].sql, where the action is do or undo — an unusually clear naming scheme for what up and down actually mean. It supports Postgres, MySQL, SQL Server and SQLite, tracks applied migrations in a schema table, and validates checksums to detect migration files edited after the fact.
That checksum validation is a genuinely good safeguard: editing an already-applied migration is a classic way to get environments quietly out of sync. MIT licensed. It also accepts JavaScript modules that generate SQL dynamically, which is an escape hatch worth knowing about.
Migration SQL Generator
Ours does the part the others deliberately leave alone: describe a schema change and get matching up and down SQL for Postgres or MySQL, including the safe ordering for a live table. Safe ordering is the detail that separates a migration that deploys quietly from one that takes a table offline — adding a column with a default, backfilling, and adding a constraint are three steps for a reason.
What it does not do: apply migrations, track versions, or manage a migration directory. It is not an alternative to golang-migrate or Flyway; it is the step before them. Write the SQL here, put it in your migration files, and let the runner do what runners do. The Postgres documentation on ALTER TABLE is worth consulting for which operations take which locks — that is ultimately what decides whether a migration is safe on a live table.
Which one to pick
- A database outside the usual few — golang-migrate’s 25+, or Flyway’s 60+.
- A Node project with plain SQL — Postgrator.
- An established tool with commercial support available — Flyway.
- Writing the up and down SQL in the first place — the tool below.
How to do it with Migration SQL Generator
- Open the Migration SQL Generator and describe the schema change.
- Read the down migration as carefully as the up one — that is the half that gets skipped.
- Check the ordering for live tables: add nullable, backfill, then constrain.
- Paste both halves into your migration runner’s file pair and test the rollback in staging.
The walkthrough is in how to write a reversible database migration. Other developer tools are in the tools directory.
You might also need
If the schema is being derived from existing data, the JSON to SQL Schema Generator produces the starting table definitions.
The GitHub Actions Workflow Builder covers running migrations as a deployment step rather than by hand.
Frequently asked questions
Is there a free database migration tool?
Yes — golang-migrate and Postgrator are open source, and Flyway’s community edition is free. All three apply migrations; none of them writes the SQL for you unless you pay for Flyway’s commercial diff generation.
Why does my migration lock the table?
Because of the specific operation. Adding a column with a non-null default, changing a column type, or adding a constraint that requires validation can each rewrite or lock a table. Splitting the change into steps — add nullable, backfill in batches, then constrain — avoids most of it.
Do I really need a down migration?
You need a plan for going backwards, and a down migration is the cheapest form of one. Some changes genuinely cannot be reversed — dropping a column loses the data — which is exactly why writing the down half forces you to notice before deploying rather than afterwards.
Final thought
Write the down migration first, before the up one. It takes two minutes, and it turns “can we roll this back” from a question asked during an incident into one answered before the deploy.