db-change-management

Database change management

Schema change against something that has to stay up.

Why this exists

Schema change is treated as ordinary application change and behaves nothing like it. The failure modes are different, and none of them show up in a test suite.

The characteristic incident: a migration that took forty milliseconds on a developer's laptop and eleven minutes on a forty-million-row production table, holding a lock the whole time, while every request queued behind it. The migration was correct. The test passed. The site was down.

The second characteristic incident is ordering. The application deploys before the column exists, or the old code is still running when the column is dropped. Both are avoidable by construction, and both are common because the deploy pipeline treats schema and application as one step when they are two.

When this applies

• Any schema change on a system that stays up
• Adding, dropping, or altering a column on a large table
• Adding an index, a constraint, or a foreign key to existing data
• A migration that must be reversible
• The order between schema and application deploy matters

When it doesn't

• Greenfield with no data and no users
• A maintenance window is genuinely available and agreed — the constraint disappears, though reversibility still matters
• The change is to a small, low-traffic table and you've confirmed the row count

Prerequisites

• Locate the workspace: FDE_WORKSPACE, else the charter Location, else .fde/, else ../<repo>-fde/
• .fde/traces/data-model.md or data-archaeology — you need to know the eras and the real shape
• .fde/06-blast-radius-*.md — ring 5 especially, who else reads this table
• Row counts and table sizes from the actual production database, not from staging. If you cannot get prod numbers, stop and put that in 00b-access.md. Do not classify the lock from staging.

Procedure

1. Get the real numbers first

Staging is not production, and the difference is the whole risk.