Adding a new column is one of the most common schema changes, yet also one of the most misunderstood. Done well, it is seamless and safe. Done poorly, it can lock queries, block writes, and cause outages. Whether you’re evolving a Postgres table or scaling a MySQL cluster, the mechanics are the same—your migration must be fast, consistent, and reversible.
A new column starts with a definition. In SQL, you use ALTER TABLE with an ADD COLUMN statement. Example:
ALTER TABLE users
ADD COLUMN last_login TIMESTAMP;
This change looks simple, but production databases rarely make it so. On large datasets, ALTER TABLE can be a blocking operation. The database may need to rewrite the entire table, holding locks for minutes or hours. For high-traffic systems, that is unacceptable.
To add a column to a live system, minimize downtime. First, choose a migration tool or process that supports non-blocking schema changes. For Postgres, ALTER TABLE ... ADD COLUMN without a default value is typically fast because it updates only metadata. For MySQL, use tools like gh-ost or pt-online-schema-change to avoid locking the table.
Default values require care. Assigning a default in the ADD COLUMN command can trigger a table rewrite. Instead, add the column as nullable, backfill data in small batches, then set the default and constraints in a subsequent migration.