Adding a new column is one of the most common schema changes, yet when done wrong it can stall deploys, lock tables, or break production. The work sounds simple: add a field, store more data. But at scale, a poorly executed ALTER TABLE can block reads, increase replication lag, or trigger downtime.
A new column should start with a clear purpose. Decide on the exact data type, nullability, default values, and indexing before touching the database. Understand how your ORM maps this change to SQL, and how that SQL behaves under load. Columns added with a non-null default often cause a full table rewrite; this is fine for small datasets, fatal for large ones.
Use a safe rollout pattern. In PostgreSQL, add the new column nullable with no default to avoid long locks. Backfill data in small batches to prevent pressure on replication. When defaults are required, set them in application code first and later alter the column to enforce them. For MySQL, consider ALGORITHM=INPLACE or ALGORITHM=INSTANT when supported, but confirm behavior with your exact storage engine.