The data was correct. But the schema had changed, and you needed a new column.
Adding a new column is simple in concept but can carry heavy consequences in production. It alters the shape of the data. It changes how queries run, how indexes work, and how application code maps results. In fast-moving systems, the wrong approach can create downtime or corrupt data at scale.
Start by defining the new column with absolute clarity. Name it in line with existing conventions. Pick the smallest data type that fits current and near-future needs. Decide on nullability up front. A column that allows nulls behaves differently in joins, constraints, and aggregations.
In SQL, adding a new column is often one line:
ALTER TABLE orders ADD COLUMN processed_at TIMESTAMP NULL;
But this line can lock the table for longer than expected, depending on the database and table size. In PostgreSQL, adding a nullable column without a default is cheap, but adding a default value rewrites the table. MySQL or MariaDB may require online DDL or tools like pt-online-schema-change to avoid blocking writes.