The logs showed why: a missing new column.
When adding a new column to a production database, precision matters. Define the column with explicit data types and constraints. Avoid NULL defaults unless intentional. In SQL, a new column can be added with a simple ALTER TABLE statement, but the impact can be wide. Schema changes cascade into models, APIs, and front-end dependencies.
The safest way to add a new column is through controlled deployment. Plan the change. First, add the new column without dropping or renaming existing data. Then backfill the data carefully. Avoid locking large tables during peak traffic. For PostgreSQL, adding a column with a constant default rewrites the table. This can stall queries. In MySQL, adding a column can be instant if it’s nullable and without a default, but not always—check the version and storage engine.
Version control for schema changes is critical. Track the ALTER statement in a migration file. Link it to application commits that use the new column. Never merge code that queries a column before it exists in production. For distributed systems, deploy in phases: introduce the new column, backfill, then update services to read and write it. Last, remove any code paths relying on old structures.