The deployment failed. Not because of the code, but because the database schema was missing a new column.
Adding a new column sounds simple. In practice, it can break production if done carelessly. Schema changes touch live data. They affect reads, writes, indexes, and query plans. A bad migration can lock tables, cause downtime, or corrupt data. This is why production-grade systems treat each new column as a controlled operation, not a quick patch.
The safest way to add a new column is to use an explicit migration. Define the column, its type, and constraints with precision. Avoid adding heavy defaults that force a full table rewrite in one step. For large datasets, break changes into multiple stages. First, add the nullable column. Backfill in batches. Then enforce NOT NULL or add indexes after the data is in place and verified.
Test migrations against a copy of production data. This reveals slow queries and locking risks before they hit users. Time the migration to avoid peak traffic. Monitor closely during and after deployment. Schema changes should be idempotent and reversible; a rollback plan is critical if something fails mid-process.