The table was already in production when the requirement hit: add a new column without downtime. No staging delays. No broken queries. Just a fast, clean schema change.
Adding a new column in SQL sounds simple. It can be. But at scale, even small schema changes can block writes, lock tables, or trigger long-running migrations. The risk grows with dataset size and live traffic. The goal is to add the new column in-place, keep the system responsive, and avoid service interruptions.
In PostgreSQL, ALTER TABLE ADD COLUMN is straightforward for smaller datasets. Execution is instant when the column has no default or is nullable because the database doesn’t rewrite existing rows—it just updates metadata. Problems begin when adding non-null columns with defaults. PostgreSQL rewrites every row, which can lock the table for a long time. Solutions include:
- Adding the column as nullable.
- Backfilling values in batches.
- Adding the NOT NULL constraint in a separate operation after backfill.
In MySQL, an instant ADD COLUMN is possible when certain conditions are met, depending on the storage engine and MySQL version. With InnoDB in modern versions, adding a column at the table end can be nearly instant. If defaults and ordering changes are involved, expect a full table copy. Many teams avoid risk by using online schema migration tools like pt-online-schema-change or gh-ost.