Adding a new column sounds trivial. In practice, it can be the breaking point between stable production and an outage. A schema change touches real data, live queries, and concurrent writes. Without planning, it locks tables, halts transactions, and slows the system under load.
The safest path starts with knowing the size and usage of the table. On large datasets, an ALTER TABLE can block for minutes or hours. Use online schema change tools or database-native features like ADD COLUMN ... ONLINE. For critical systems, run the change on a shadow table first, then swap it in atomically.
Default values can be dangerous. Setting a default in the schema triggers a rewrite that touches every row. Instead, create the new column as NULL, backfill in small batches, and then alter the default. This minimizes locks and keeps latency predictable.
Manage dependencies. ORM models, API contracts, and downstream consumers may expect the new column immediately or not at all. Version your application code so that the column’s lifecycle matches deploys. Deploy in phases: first add the nullable column, then write to it, then make it required.