The migration script failed. The database stopped cold, waiting for a new column that didn’t exist.
When you add a new column to a table, details matter. Schema changes can break queries, corrupt data, or lock the wrong indexes. To avoid downtime, define the column with clear types, constraints, and defaults. A NULL-friendly column may work in testing, but in production it can mask broken logic. Choose between NULL and NOT NULL based on the actual read and write patterns of the system.
Before altering a live schema, check the execution plans of all queries touching that table. Adding a new column impacts width, row size, and performance. Even if the column starts empty, it changes storage layout and cache efficiency. Run the migration on a staging environment that mirrors production data sizes. Measure query times before and after.
When adding indexed columns, create indexes in separate steps after deployment. This reduces lock time and allows background index creation if supported by the database. For high-traffic systems, consider phased rollouts: first deploy the column, then backfill data in batches, then enable constraints and indexes.