A new column can change everything. One command, one migration, and the shape of your data is different. In high-traffic systems, that change is a knife edge between a clean deployment and a production outage.
Adding a new column in relational databases is not always as simple as it looks in code. The ALTER TABLE statement can lock rows or entire tables. On large datasets, this can mean seconds or minutes of blocking — long enough to trigger timeouts, cascades of retries, and user-facing errors. Understanding the mechanics is the difference between control and chaos.
Modern Postgres, MySQL, and MariaDB all handle new columns in different ways. Adding a nullable column with no default is often instant because the database just updates metadata. But when you add a column with a non-null default value, the database must rewrite the table on disk row-by-row. That operation can be expensive.
You can mitigate risk with zero-downtime patterns. Use nullable columns first, then backfill in batches with an UPDATE job. Once complete, apply the NOT NULL constraint. This split-step migration keeps locks tiny and predictable. For schema changes in distributed databases or sharded systems, coordinate the deployment across all nodes.