Adding a new column should be simple. It rarely is at scale. Schema changes can lock tables, block writes, and turn a clean deploy into an outage. Even small changes pose risk when traffic is constant and downtime is not an option.
A new column changes the contract between your database and application. You need to define the column type, default values, constraints, and indexing strategy. Decisions about nullability, storage engine, and character sets matter. The wrong choice can cascade into performance degradation or broken features.
Work in steps. Create the new column without defaults or constraints first to avoid table rewrites. Backfill data in controlled batches, monitoring the impact on CPU and I/O. Then add constraints or indexes once the data is ready. Use feature flags or versioned code to read from the column only after it exists and is populated.
For high-traffic systems, run the DDL in off-peak windows or use online schema change tools like pt-online-schema-change or gh-ost. These tools avoid full table locks by copying rows in the background and swapping tables at the end. They reduce risk but still require careful testing in staging.