Adding a new column sounds simple. In production, it is not. Schema changes are a sharp edge. Add it wrong and you can lock a table, stall writes, or cause downtime. Done right, it becomes invisible—deployed without anyone noticing except the monitoring graphs.
A new column starts with intent. Decide the name, type, nullability, and default. In relational databases, the default is not cosmetic; it changes the cost of the alter. Adding a column without a default is fast because the database stores only metadata. Adding a column with a default value forces a write to every row.
For high-traffic systems, the difference between instant and hours is the choice of how you add that column. A best practice is to add the column as nullable with no default, backfill in small batches, then add constraints or defaults in a later migration. This makes the change safe and reversible.
In distributed environments, beware of deploy order. Application code reading from a column before it exists will fail hard. Application code writing to a column before all shards have it will fail silently. Use feature flags and staged rollout to coordinate schema and application changes.