Adding a new column is one of the most common database changes, but it can break production if done wrong. The risk is higher when data migrations run at scale or under load. Downtime, deadlocks, and inconsistent reads lurk behind what looks like a small change.
Before you add a new column, decide if it must be nullable, have a default value, or be populated from existing data. For large tables, adding a column with a default can lock writes for minutes or hours depending on the database engine. In PostgreSQL, adding a nullable column without a default is nearly instant. In MySQL, older versions require a table rebuild for most ALTER TABLE changes. On high-traffic systems, that means degraded performance or outages.
Plan for data backfill separately from the schema change. Add the new column first, then run background jobs to populate it in batches. This reduces lock contention and avoids blocking queries. Use transactional DDL where supported. Always test on production-like datasets to catch edge cases.