The database table was ready, but the shape of the data had changed. You needed a new column, and you needed it without breaking production.
Adding a new column sounds simple. It is not. Schema changes can lock rows, block queries, and take down services if done wrong. In large systems, a naive ALTER TABLE can trigger hours of downtime. The right approach is deliberate, tested, and timed.
Start with a plan. Determine the column name, data type, nullability, and default values. Audit dependent code to see what will read and write the new column. Check for database engine constraints around adding columns online. In Postgres, adding a nullable column without a default is fast. Adding one with a default rewrites the table. In MySQL, older versions require full table locks, while newer releases support instant column addition in some cases.
Use migrations with clear versioning. Roll forward with a migration that adds the column in the safest form possible. Avoid adding heavy defaults inline. Instead, add the column as nullable, backfill the data in small batches, then apply a new migration to enforce NOT NULL or constraints. This staged rollout prevents downtime and reduces replication lag.