Adding a new column sounds simple: define a name, pick a type, set a default. In production, it can be a minefield. Large tables take time to alter. Locks can stall queries. Backfills can consume I/O and crash replicas. The wrong approach turns a straightforward schema change into downtime.
The safest path starts with a plan. First, measure table size and access patterns. Confirm index usage. For large datasets, use an online migration tool or staged rollout. Add the new column as nullable to avoid heavy locks. Null columns often add metadata overhead but skip the mass write required for defaults. After deployment, backfill in small batches during low traffic, monitoring CPU, disk, and replication lag.
Use feature flags or code branching to handle partial backfills. Write service logic that tolerates nulls until migration completes. Only after the backfill and verification should you enforce constraints and defaults at the schema level. This prevents breaking reads and writes during the migration process.