Group
  • Deployment

    Deploy database migrations without breaking production

    Run schema changes safely against a live database with zero-downtime patterns and a plan for the bad case.

    • Plan & validate
    • Improve quality
    • Advanced
    • General

Free Prompt

Audit and improve how I deploy database migrations. Bad migrations are the fastest way to take a live app down, and the easy defaults (drop a column, rename a table, add a NOT NULL column with no default) are the ones that break things. Cover each of these: 1. Migration tool: confirm I'm using a real migration tool that versions migrations, runs them in order, and records what's been applied (Prisma, Sequelize, Knex, Rails, Alembic, whatever fits my stack). No hand-written SQL applied by hand. 2. Zero-downtime patterns: enforce these rules for anything running against a live database: - Adding a column: nullable or with a default. Never NOT NULL with no default on a big table; it locks the table. - Renaming/removing: use the expand-then-contract pattern: add new, deploy code that writes both/reads new, backfill, then in a later deploy remove the old. - Indexes: on large tables, create indexes concurrently (Postgres CREATE INDEX CONCURRENTLY) so writes aren't blocked. - Constraints: add as NOT VALID first, validate separately, or add after backfill. 3. Backfills: don't backfill millions of rows inside a migration transaction; run backfills as a batched background job so long-running writes don't hold locks or fail on timeouts. 4. Reversibility: every migration should have a documented reversal path, even if it's 'restore from backup taken at [step]'. Truly irreversible migrations get a mandatory pre-migration snapshot. 5. Pre-deploy validation: run each migration against staging with production-shaped data. Time it. A migration that takes 40 minutes on staging takes 40 minutes in production and needs a plan for that window. 6. Deploy order: for anything schema-breaking, run migrations first, then deploy new code, so old code never runs against the new schema mid-rollover. Don't accept 'the ORM handles it' as safety. The deliverable is the migration policy documented in the repo, any recent risky migrations rewritten to zero-downtime patterns, a snapshot-then-run process for irreversible changes, and one migration deployed to production following the new checklist to prove it works.

What This Does / How This Helps

This puts guardrails on schema changes: enforce zero-downtime patterns, batch backfills, time migrations against staging with real-shaped data, snapshot before irreversible changes, and run migrations before code deploys. Migrations are the single most common cause of self-inflicted outages once an app has real users. A drop-column runs in a millisecond on your laptop and holds a lock for two minutes in production while every table read piles up behind it. The rules above aren't paranoid; they're the difference between 'migration ran' and 'migration ran and no user noticed'.

Want to skip doing this by hand?

Fortivibe audits your app for all of the areas these prompts cover (and more).

See What We Check

Related Prompts