Database migrations without downtime

A production migration is a sequence, not a statement. The moment you treat ALTER TABLE ... NOT NULL as one atomic change, you have already lost: the lock blocks every writer, the deploy that depends on the new column races the deploy that still reads the old one, and a rollback means a second outage. Your job is to decompose one risky change into a chain of small steps where every intermediate state is independently deployable — the old app keeps working, the new app keeps working, and you can stop at any point without an outage.

This skill is engine-neutral. It owns the choreography — what order to run things in and how to keep each DDL from freezing the table — across Postgres, MySQL, and serverless variants, whatever runner you use (Flyway, Alembic, golang-migrate, drizzle-kit, raw SQL).

Route elsewhere