Adding a new column should be the fastest part of schema evolution. Too often, it becomes a slow, risky operation that can block deploys and break running code. Databases handle columns differently. In some systems, adding a column with a default value rewrites the entire table. On large datasets, this can lock queries, inflate storage, and cause downtime.
A new column means more than ALTER TABLE. You need to check indexing impact, storage alignment, and whether the column should be nullable. Adding constraints later can be safer than doing it at creation time. For high-traffic systems, online schema change tools like gh-ost or pt-online-schema-change can keep reads and writes flowing during the migration.
Plan for how the application rolls out the change. Feature flags can guard new code paths while older versions run against the previous schema. In a zero-downtime release, the sequence is usually: add the column, deploy code that writes to it, backfill in batches, deploy code that reads from it, then make it required.