The query finished running, but the result was wrong.
A missing field in the table broke the logic.
You need a new column.
Adding a new column sounds simple. It is not. Done wrong, it adds risk, downtime, and silent bugs. Done right, it is fast, safe, and reversible. The difference is process.
When you add a new column to a production database, start with the schema change itself. Use a migration tool that supports transactional DDL or online schema migration. For MySQL, pt-online-schema-change or gh-ost can run without locking the table. For PostgreSQL, adding most columns is fast, but watch for defaults with non-null constraints, which can rewrite the whole table.
Decide on the column type with care. Match it to the exact data you expect. Avoid generic types. Keep it narrow: smaller data types reduce memory use, disk footprint, and cache churn. Set nullability rules that match your data model now, not just later guesses.
If the column will hold derived or backfilled data, deploy in phases. First, add the column as nullable. Then backfill the data in small batches to avoid write amplification and replication lag. Monitor replica lag in real time if you use read replicas. Only then set NOT NULL or add unique constraints.