In relational databases, adding a new column is common. But if done poorly, it can break production, trigger downtime, or corrupt data. The right approach depends on your database engine, traffic patterns, and deployment pipeline.
In SQL, the simplest pattern is:
ALTER TABLE users ADD COLUMN last_login TIMESTAMP;
This works for small tables or local development. On large tables in production, ALTER TABLE can lock writes for seconds or minutes. In high-traffic environments, that’s unacceptable.
To add a new column safely, many teams:
- Create the column in a non-blocking way if supported (
ADD COLUMNis online in PostgreSQL ≥ 11 for some cases, MySQL withALGORITHM=INPLACEwhere possible). - Deploy code that writes to the new column, but does not read from it yet.
- Backfill data in small batches to avoid I/O spikes.
- Switch application reads to the new column only after data is complete.
For non-nullable columns with defaults, avoid defining the default in the ALTER TABLE if it forces a full table rewrite. Instead, add the column nullable, backfill, then alter it to set NOT NULL with a default.