Adding a new column sounds simple. It can break production if you do it wrong. Schema changes carry risk. Downtime, locks, bad migrations—they all start with one line of SQL. The goal is zero impact to live queries and zero rollback surprises.
First, decide on the column type and nullability. Changing these later costs more than adding them right the first time. Use explicit defaults only when you can set them without locking the whole table. For large tables in PostgreSQL, adding a column with a default will rewrite the table. Avoid it. Instead, add the column without a default, backfill in small batches, then set the default in a separate statement.
For MySQL, watch for metadata-only changes. Certain operations are instant in newer versions. But not all. Test your migration plan against production-like data volumes. Confirm index changes. New columns often lead to new queries, which means new indexes. Plan them together.