The database was live, the clock was ticking, and the schema needed to change. A new column had to be added without breaking production.
A new column is one of the most common schema changes. It sounds simple but can create downtime, data loss, or inconsistent reads if done carelessly. Large tables, high write volumes, and strict uptime requirements all raise the stakes.
To add a new column safely, start by understanding the database engine’s behavior. Some engines lock the entire table during an ALTER TABLE operation. Others stream changes in the background but still risk slow queries. For PostgreSQL, adding a nullable column with no default is instant. Adding one with a default value rewrites the table and can block other operations. For MySQL, even simple additions may trigger full table copies depending on storage engine and configuration.
Plan the change in stages. First, deploy code that can handle both schema versions. Then, create the new column with settings that avoid table rewrites when possible. If the column requires a default or non-null constraint, backfill data in small batches to prevent spikes in load or replication lag. After the data is populated, enforce constraints in a separate migration. This keeps each step short, reversible, and observable.