Adding a new column sounds simple, but execution under production load demands precision. Schema changes can lock tables, spike latency, and break services if done without planning. The safest path depends on your database engine, table size, and uptime requirements.
In PostgreSQL, an ALTER TABLE ... ADD COLUMN is usually fast if the column has no default. Adding a column with a non-null default rewrites the table, which can be expensive. The common pattern is to add the column with a null default, backfill in batches, and then set the default. MySQL behaves differently. Older versions rewrite the table for any new column addition. Recent versions with ALGORITHM=INPLACE or INSTANT can add columns without full table copies for certain data types.
For distributed systems, deploy the schema change before deploying code that uses it. This reduces the risk of runtime errors from missing fields. In application code, write fallbacks for when the new column is null. For large datasets, use background jobs or online schema migration tools like pt-online-schema-change or native online DDL features to avoid downtime.