Adding a new column sounds simple. In production, it can be the point where a deployment collapses. Schema changes are high-risk because the database is the backbone of everything else. When you add a column, you are changing the contract that every dependent service relies on.
The first rule: define the new column with precision. Choose the correct data type. Decide if it allows null values. Set default values only when they truly make sense. Adding a default to a massive table without a careful plan can lock writes and spike CPU.
The second rule: deploy in small, reversible steps. For most relational databases, adding a nullable new column without defaults runs faster because it skips rewriting the whole table. If you need a non-null column with a default, consider adding it in two stages—first nullable, then populated, then constrained.
The third rule: understand the impact on reads and writes. Even if the new column is empty, certain engines rebuild indexes or trigger replication events. Measure these effects in a staging environment with production-sized data.