The data was there, but something was missing: a new column.
Adding a new column in a live database is one of the most common schema changes. Done right, it's fast and safe. Done wrong, it can block writes, lock tables, and bring down services. The process is simple, but the details decide whether your migration succeeds or fails.
The first choice is additive versus destructive change. Adding a new column is additive. It minimizes risk because old queries still run. But you still need to plan the column’s type, default values, and nullability. Skip those decisions and later code will break.
In SQL, adding a new column is as direct as:
ALTER TABLE users ADD COLUMN last_login TIMESTAMP;
But the DDL statement’s impact varies between databases. In Postgres, adding a column with a default value rewrites the table. On large datasets, this can lock reads and writes for minutes or hours. To avoid downtime, first add the column as nullable without a default. Then backfill in controlled batches. Finally, set the default and NOT NULL constraint if needed.