A new column is one of the most common schema changes, yet it is also one of the most dangerous. In production databases, especially at scale, a poorly executed ALTER TABLE can lock writes, spike CPU, and stall services. Downtime starts here more often than most teams will admit.
When you add a new column, the operation touches every row. On large tables, that means billions of updates. Some databases rewrite the entire table. Others block reads. Each engine—PostgreSQL, MySQL, SQL Server—handles it differently. You need to know exactly what your system does before you run the migration.
The steps matter. In PostgreSQL, adding a nullable column with no default is fast, almost instant, because the engine stores a metadata change. Setting a default value on a new column for an existing large table, however, forces a table rewrite. In MySQL, the approach changes with storage engine and version. With InnoDB, adding a column can require rebuilding the table unless you use ALGORITHM=INSTANT on supported versions.
Never test live. Run the migration in staging with production-sized data. Measure the lock time. Measure replication lag. Watch vacuum and analyze tasks after the new column lands. Your indexes matter too: adding a column might mean creating a new index, which is another heavy operation.