The code was ready to ship until you realized the schema needed a new column.
Adding a new column sounds small. In production, it is not. A single ALTER TABLE can lock writes, stall queries, or trigger cascading changes across services. The difference between a smooth deployment and a costly outage lies in how you plan and execute the change.
When you add a new column, start by defining its purpose and data type with precision. Choose defaults carefully. A poorly chosen default can bloat storage or create misleading data. If the column is nullable, decide how you will handle legacy rows. If it is required, plan how to populate it without blocking writes.
In relational databases, adding a column can be instant or slow depending on the engine and version. PostgreSQL can add nullable columns with a default in constant time since version 11. MySQL may still rewrite the table. Always test schema migrations in staging with production-sized data before touching live systems. Measure the operation’s duration and memory usage.