The logs pointed to a simple cause: a missing new column.
Adding a new column is a common database change, but its impact can be deep. Schema updates that seem harmless can lock tables, slow queries, and break production if done without care. A well-planned new column addition must balance consistency, performance, and backward compatibility.
First, define the exact name and type. Avoid vague names that need comments to explain them. Pick the smallest data type that fits the range you expect. Smaller types mean less storage and faster indexes.
Second, decide on nullability and defaults. Adding a new column with a non-null constraint can force a full table rewrite. Defaults applied at the schema level can lock rows during the change. In high-traffic systems, it is often safer to add the column as nullable, backfill data in small batches, then set constraints after.
Third, understand the operational cost. In some SQL engines, adding a new column without a default is instant. In others, it will rewrite every row. Test on a staging environment with production-sized data before touching live systems.