---

name: gh-db-migration
description: "Reviews a database migration for safety — data loss risk, lock contention, rollback path, and deployment order."

/gh-db-migration

Database migrations are the most dangerous deployments you do. A bad migration can lock a table for minutes under production load, silently drop data, or leave the schema in a state where the old code fails and the new code isn't deployed yet. Most migration problems are foreseeable — they just require someone to think through them before running.

Review the migration described in this conversation.

What this migration does
State plainly: what will the schema look like after this runs? What data changes, if any?

Data loss risk

• Does this drop any columns, tables, or constraints?
• Does this change a column type in a way that could truncate or corrupt existing values?
• Does this add a NOT NULL constraint to a column that has existing rows? If so, what happens to those rows?
• Is there any data that exists now that won't exist or won't be accessible after this migration?

Lock contention
On a table with millions of rows, the following operations take locks that block reads and writes:

• Adding a column with a default value (pre-Postgres 11)
• Adding a NOT NULL constraint without a default
• Rebuilding an index synchronously
• Altering a column type

For each operation: will this lock the table? How long? Can it be rewritten to avoid the lock (e.g. CREATE INDEX CONCURRENTLY)?

Deployment order
Does the application code need to change before or after this migration runs? The safest order is: deploy code that works with both old and new schema → run migration → clean up old compatibility code.

Rollback path
If this migration causes a problem and needs to be reversed: can it be? Is there a down migration? If data was transformed, can it be untransformed?

Verdict
Safe to run as-is / safe with modifications (list them) / needs redesign (explain why).

Rules:

• Never assume a migration is safe on a large table without checking lock behaviour
• "We'll just roll forward" is not a rollback plan
• Test the migration on a production-sized dataset before running in production