Adding a new column is simple in concept, but in production systems it can be dangerous. Schema changes lock tables, slow queries, or even take entire services offline if done carelessly. The key is using the right commands, the right sequence, and the right environment to minimize risk.
In SQL, the command is direct:
ALTER TABLE users ADD COLUMN last_login TIMESTAMP;
This works for PostgreSQL, MySQL, and most relational databases with only small syntax changes. But the pitfall is not the command itself—it’s understanding what happens under the hood. Adding a new column with a default value in PostgreSQL rewrites the table, which can block writes for a long time. In MySQL, the operation might also require a full table copy, depending on the engine and schema.
Best practice for large tables is to first add the column without a default, then backfill in batches, and then apply a NOT NULL constraint if needed. This avoids long locks and keeps services running under high load. For example:
ALTER TABLE users ADD COLUMN last_login TIMESTAMP NULL;
Then backfill in application code or via a migration script: