A new column sounds simple. In practice, it can be the fastest way to break production if you get it wrong. Adding one changes the schema, shifts queries, and can cascade through services. The database must handle it without locking critical tables or corrupting data.
When creating a new column, define the exact data type first. Avoid implicit conversions. Set NULL constraints deliberately. If the column is used in indexes, create them after the initial write, not during schema alteration, to prevent long locks.
In PostgreSQL, use ALTER TABLE ... ADD COLUMN with DEFAULT only when you can tolerate a table rewrite. For large datasets, add the column without a default, backfill in small batches, then set the DEFAULT and constraints in a separate step. This keeps migrations online.
In MySQL, watch for unexpected table rebuilds with ALTER TABLE. If you use InnoDB, some operations may be instant for metadata-only changes, but type or default mismatches can trigger full copies. Always check execution plans before running in production.