Adding a new column is one of the most common schema changes, yet it can stall deploys, lock tables, and break production if handled poorly. In high-traffic systems, the gap between pushing code and shipping schema changes can be dangerous. A single blocking migration can cascade into failed queries, bad data, and lost revenue.
A new column should appear fast, without downtime. The approach depends on your database engine and your traffic profile. In PostgreSQL, ALTER TABLE ADD COLUMN is fast for nullable fields with defaults of NULL. But if you assign a non-null default, the database rewrites the entire table. On large datasets this can lock writes for minutes or hours. In MySQL, even adding a nullable column can trigger a table copy. Online schema change tools like gh-ost or pt-online-schema-change stream updates without locking the full table, but they add operational complexity.
Before adding a new column, measure table size and check for existing locks. Deploy the application code to handle the new column before the migration runs. In multi-step deploys, you may add the column, backfill data in batches, then enforce constraints in a later migration. This minimizes contention and keeps the system online.