Adding a new column should be simple. In most systems, it’s not. Schema changes can trigger downtime, data loss, or a migration that drags for hours. The first rule: understand the storage engine. The second: decide how the column is initialized. The third: control its deployment so no request ever sees a half-finished shape.
Relational databases like PostgreSQL and MySQL handle new column operations differently. In PostgreSQL, adding a nullable column without a default is nearly instant. Adding one with a default rewrites the whole table. MySQL can do in-place changes for some types, but the limits are strict. The wrong statement can lock writes.
In distributed environments, schema changes must be coordinated. Rolling out a new column across shards or replicas needs version flags in application code. First deploy a version that can read both the old and the new shape. Then run the migration. Finally, clean up unused paths. This removes race conditions and keeps data consistent.