Adding a new column should be simple. In practice, it is where databases reveal their weight. Schema changes touch every query, every index, every piece of code that reads or writes the table. Done right, they are clean. Done wrong, they break production.
A new column in SQL is more than an ALTER TABLE command. It is a change in your data model and contract with your application. The database must allocate space, update metadata, and rewrite storage pages when needed. On massive datasets, this can lock tables, stall writes, or trigger replication lag. Some engines optimize with metadata-only additions, others rewrite files. Understanding your system determines whether you push the change online or schedule downtime.
When adding a new column to PostgreSQL, the operation is often fast if you define it without a default. When adding a default or a constraint, expect a rewrite. MySQL’s behavior depends on the storage engine; InnoDB handles many additions online, but certain types of changes still block. In distributed systems like CockroachDB, schema changes run as transactions over time, reducing impact but adding complexity.