The deployment was flawless until the database schema changed. A new column appeared. Everything started to break.
Adding a new column sounds simple. In practice, it can be the trigger for downtime, slow queries, and hidden data mismatches. Schema changes in production must be handled with precision. The wrong approach can lock tables or cause application errors when old and new code run at the same time.
When introducing a new column in SQL—whether in PostgreSQL, MySQL, or any other relational database—you must plan for compatibility. First, create the column with a safe default or allow nulls. This ensures existing data stays valid and queries keep working. Avoid heavy operations like adding a column with an immediate non-null constraint or computed default on large tables. They can cause long locks and block writes.
Apply migrations in small steps. Add the column. Deploy code that starts writing to it. Backfill data in controlled batches, monitoring load and slow queries. When the backfill completes, add constraints if needed. This decouples schema changes from business logic changes, reducing release risk.