The logs screamed one reason: the database schema lacked the new column.
A new column is one of the simplest schema changes you can make, but it is also one of the most common sources of production errors. Adding a column affects your data model, queries, indexing, and application logic. Done wrong, it slows deployments, breaks compatibility, and costs you sleep. Done right, it becomes a safe, automated, and reversible step in your release pipeline.
When you add a new column to a relational database table, you decide its name, type, nullability, and default value. You also decide whether it will be populated immediately with backfilled data or lazily updated over time. Always think about performance. Adding a column with a non-null default can lock the table for longer than your SLA allows. This is why engineers often add the column as nullable first, backfill in batches, then enforce constraints later.
Consider how your application code interacts with the new column. Feature flags can help you deploy schema changes before referencing them in production code. This minimizes downtime and lets you roll forward or back without breaking requests. Make sure your ORM migrations and raw SQL changes are consistent, and ensure tests cover the transition between old and new schema versions.