A new column seems simple. It rarely is. Adding it in a production database means touching schema, migrations, code, tests, and possibly data backfills. In systems with high traffic and zero downtime requirements, a careless change can lock tables, block writes, or break deployment pipelines. The cost of mistakes can cascade fast.
When you add a new column in SQL, the first decision is whether it can be generated with a default or null value. In PostgreSQL, adding a nullable column without a default is instant. Adding one with a default on a large table can lock the table during the update. MySQL has similar caveats, but behavior depends on storage engine and version. Always check the version-specific docs before executing ALTER TABLE.
Plan the migration with two steps: first, add the column as nullable and without a default to avoid locking. Deploy that. Then, backfill data in controlled batches. Finally, add constraints or defaults in a separate migration if needed. This staged approach keeps the schema change safe under load.
In ORM-based codebases, update the model definitions only after the first migration has been applied. This prevents app code from trying to use the column before it exists. If you need the new column to be indexed, create that index in yet another migration. Index creation can be just as disruptive as the column addition if done carelessly.