Adding a new column is one of the most common schema changes in software projects. Done right, it’s fast, safe, and invisible to the end user. Done poorly, it can lock tables, stall writes, and crash services under load. Whether you’re using PostgreSQL, MySQL, or a managed database, the principles are the same: plan the change, execute with minimal impact, and verify.
Before running ALTER TABLE ADD COLUMN, check if the column needs a default value. Adding a non-null column with a default can rewrite the whole table, which is expensive for large datasets. In PostgreSQL 11+, adding a column with a constant default is metadata-only, but older versions still require a rewrite. For MySQL, check the engine and version—InnoDB behaves differently than MyISAM.
Always run schema changes in environments that match production before deploying. Measure the impact on query plans and replication lag. Long-running alters can delay replication, cause failovers, or desynchronize read replicas. For mission-critical databases, use phased rollouts: add the new column as nullable, backfill in batches, then enforce constraints.