Adding a new column sounds simple. It rarely is. Schema changes in live databases can block writes, lock reads, or spike replication lag. The impact grows with the size of the table and the fragility of the workload. A poorly executed column addition can stall critical paths, corrupt data, or force a painful rollback.
To do it right, you start by defining exactly what the new column must store. Choose the smallest appropriate data type. Consider nullability and default values carefully. In many relational database systems, adding a column with a non-null default will rewrite the entire table — a dangerous operation at scale. Use null defaults when you can, then backfill in controlled batches.
For PostgreSQL, ALTER TABLE ... ADD COLUMN with a null default is usually instant, but adding with a default value triggers a table rewrite in versions prior to 11. MySQL’s ALTER TABLE often rebuilds the table unless you leverage ALGORITHM=INPLACE and LOCK=NONE, and even then it depends on the engine and version. In high-traffic systems, run the operation on a replica first to measure performance impact, then promote.