The query took thirty seconds to run before anyone spoke. Then someone said it out loud: we need a new column.
Adding a new column is the smallest database change that can cascade into days of deployment risk. Schema migrations, lock contention, index rebuilds, and stale caches can turn what should be a quick modification into an outage. The challenge is not in writing ALTER TABLE. The challenge is introducing the change without blocking queries or corrupting data.
A new column definition must be explicit. Choose the correct data type with precision. Use NULL defaults or backfill values in separate steps to avoid rewriting the entire table at once. On large datasets, run the migration in batches and track row counts. For high-traffic systems, consider creating the column without constraints, then applying not-null or unique constraints after the backfill completes.
Indexing a new column should be deliberate. Adding indexes during the initial migration can lock the table for too long. Instead, deploy indexes asynchronously and monitor query performance as they come online. If the column will be part of joins or WHERE clauses, choose index types that match the expected query patterns.