The database groaned under the weight of a growing table. You needed a new column, and you needed it now.
Adding a new column sounds simple. In production, it can be anything but. Schema changes touch live data, impact queries, and carry risk if the migration is slow or locks the table. The wrong approach can freeze writes, spike CPU, or block requests. The right approach keeps uptime intact and rollouts safe.
Start with the question: is this an additive schema change? Adding a nullable column without a default is often instant. Adding a column with a default writes to every row. On large datasets, that means a full table rewrite. For PostgreSQL, MySQL, and other relational systems, this can lock the table.
Plan the change in steps. First, deploy an additive, metadata-only change if your database supports it. Avoid immediate mass updates. If you need a default value, backfill it in small batches after the column exists. Use an online migration tool like pt-online-schema-change for MySQL or pg_online_schema_changes for Postgres to reduce locking issues. Always test on a replica or staging database with production-like data to measure migration time.