Adding a new column to an existing database table should be fast, explicit, and predictable. Done right, it improves your schema without risking downtime or corrupt data. Done wrong, it can lock tables, break queries, and trigger cascading failures across dependent services. The key is applying migrations that are safe, reversible, and visible to your team before they hit production.
In SQL, adding a new column is handled with an ALTER TABLE statement. The exact syntax and behavior depend on the database engine. In PostgreSQL:
ALTER TABLE users ADD COLUMN last_login TIMESTAMP;
In MySQL or MariaDB:
ALTER TABLE users ADD COLUMN last_login DATETIME;
Default values, NOT NULL constraints, and indexes should be considered at creation time. Adding a column with a default on a large table can rewrite all rows, causing locks. For high-traffic systems, the safer pattern is:
- Add the new column as nullable, without defaults.
- Backfill the column in small batches.
- Add constraints or defaults in a second migration once the column is populated.
This approach minimizes load on your database and reduces the risk of blocking writes.