Adding a new column is one of the most common schema changes, but it can still break production if handled carelessly. The operation may seem simple: define the column, set its type, apply constraints. Yet details matter. Will the column allow NULLs during migration? How will it populate existing rows? Is an index necessary, and can you create it without locking writes?
In SQL, a new column starts with ALTER TABLE. For example:
ALTER TABLE users ADD COLUMN last_login TIMESTAMP NULL;
This works, but in large datasets, the cost of altering a table can be high. Some databases lock the table until the operation finishes. Others, like PostgreSQL for certain data types, can add columns instantly if they have a default of NULL. Non-null defaults often trigger a table rewrite. Understanding these behaviors prevents downtime.
For production systems, always test DDL changes in a staging environment with realistic data volumes. Check the migration plan. Measure execution time. Consider breaking the change into phases: add a nullable column first, backfill in small batches, then apply a NOT NULL constraint when complete.