A new column can change the shape of your data model, fix a gap in reporting, or unlock the next feature release. But adding one in production is never just a schema tweak. Done wrong, it locks tables, blocks writes, and triggers rollbacks under pressure. Done right, it slips into place while traffic flows and transactions commit without a pause.
Modern databases have native support for adding a new column with minimal locking. In PostgreSQL, ALTER TABLE ADD COLUMN runs fast when defaults are NULL and constraints are set later. In MySQL, ALTER TABLE can still cause full table rebuilds unless you use ALGORITHM=INPLACE where supported. In distributed SQL engines, the operation can be non-blocking, but changes must propagate to all nodes before being safe to use.
Planning matters. Test the migration on a clone of production data. Measure run time. Avoid non-null defaults that rewrite the entire table. Keep new columns nullable at first, backfill in batches, and then enforce constraints only after the data is consistent. This reduces lock contention and avoids unnecessary downtime.