Adding a new column to a production database sounds simple. It is not. Every schema change touches code, queries, indexes, and the flow of live traffic. Get it wrong, and the system stalls—or worse, corrupts data.
The safest path is to design the new column with forward compatibility. Add it without breaking existing reads. Backfill in small, controlled batches to avoid locking tables. Monitor query plans before and after, because even a nullable column can trigger an index rewrite.
In SQL, the command is straightforward:
ALTER TABLE users ADD COLUMN last_login_at TIMESTAMP NULL;
On a large table, this command can block writes if not handled with care. Use tools like pt-online-schema-change for MySQL or ALTER TABLE ... ADD COLUMN with LOCK=NONE when supported. For Postgres, adding a new column with a default value is not immediate—it rewrites the whole table unless managed in two steps.
Application code should treat the new column as optional until fully populated. This means feature flags, conditional logic, and staged rollouts. Remove the flags only after the data is consistent and performance stable.