Postgres schema migration

Not a section of awesome-postgres — a category assembled across three of them (CLI, Utilities, GUI), because roughly twenty-five entries in that catalog are about changing a schema safely and the catalog files them by interface rather than by job. Recorded at the catalog's word (T3) on 2026-08-20.

It gets a page because it is the largest unpaged functional category in the corpus, and because logical-replication ends on it: schema changes are not replicated, so a migration must be applied on both sides in a compatible order by something outside the replication system. Everything below is that something.

Versioned migration runners — the classic model

flyway (schema migration tool) · sqitch (versioned schema deployment) · pgmigrate (CLI for schema migration evolution) · pg_migrate (manage PostgreSQL codebases) · Pyrseas (database schema versioning) · alembic-class tools are absent from the catalog

An ordered series of scripts with a recorded version. The model everyone starts with, and the one that cannot answer "what is actually in production right now."

Declarative / diff-based — describe the target, generate the steps

atlas (schema management and migration) · pgschema (Terraform-style declarative migration) · pg-schema-diff (diff schemas, generate SQL) · migra (schema diff tool) · apgdiff (compares dumps, creates update DDL) · pgcmp (compare database schemas) · pg-differ (structure initialization and updating) · PostgresCompare (commercial)

Eight entries for one idea: store the desired end state, compute the diff. The trade against versioned runners is the same one infrastructure-as-code made a decade earlier, and this many independent implementations suggests nobody has made it fully safe yet.

Safety linting — refusing the dangerous DDL

MigrationPilot (detecting dangerous DDL) · pg-safe-migrate (safety-first migration engine with linting) · diesel-guard (linter for dangerous migration patterns) · sqlcheck (detects common SQL anti-patterns)

This subcategory exists because of one Postgres fact the corpus should eventually page properly: some ALTER TABLE forms take an ACCESS EXCLUSIVE lock and block every reader, so an innocuous-looking migration can stop a production database. Four separate linters is what that hazard costs the ecosystem.

Zero-downtime and reversible

pgroll (zero-downtime, reversible schema migrations) · pgsh (branch databases like Git) · bemi (automatic data change tracking) · RegreSQL (regression testing suite for queries) · pgTAP (database testing framework, catalogued under Extensions)

pgroll is the highest-value primary read in this whole category. Reversible, zero-downtime schema change means running two schema versions at once behind views while clients migrate — which is a genuine distributed-systems problem in a single database, and the direct answer to the lock hazard above.

Documentation and modelling as inputs

schemaspy · pgModeler · planter (PlantUML ER diagrams from tables) · ERAlchemy (ER diagrams from databases) · Luna Modeler · pdot

Why this belongs in this spoke

The spoke's boundary rule sends database client, migration, backup and monitoring tooling here rather than to ../dev-tooling-wiki, per the founding awesome-db-tools source. Schema migration is the case that tests it hardest — it is version control applied to a database — and it stays here because the hazard being managed is a database mechanism (locking, replication, MVCC), not a build-and-ship one.

Next candidates

pgroll (two live schema versions), then atlas (the most complete declarative implementation), then one safety linter to enumerate which DDL forms are actually dangerous.

logical-replication · postgres-cli-tooling · multiversion-concurrency-control · awesome-db-tools · awesome-postgres · operational-databases