The new column waited, empty and clean, in the schema. It was the smallest change in the codebase and the one most likely to break everything if done wrong.
Adding a new column in a database looks simple: define the field, set the type, run the migration. But live systems are not notebooks. Schema changes touch production. Transactions slow. Locks block requests. Queries that once ran in milliseconds can hang.
The safest way to add a new column is to do it in steps. First, deploy the column without constraints or defaults. For large tables, use a method that avoids full table rewrites. Next, backfill data in small batches to avoid load spikes. Finally, add indexes, constraints, and defaults in separate operations. This reduces lock contention and keeps the service responsive.
In PostgreSQL, ALTER TABLE is powerful but dangerous. Adding a column with a default value before Postgres 11 rewrote the whole table. In MySQL, even minor changes can trigger table rebuilds if you pick the wrong data type. Rollout strategies like zero-downtime migrations, feature flags, and blue-green deployment mitigate these risks.