The schema had changed, but no one had added the new column.
Adding a new column should be simple. In reality, it’s a point where teams ship bugs, lose data, and slow deployment. Database migrations often live in the shadows, ignored until they fail in production. The key to handling a new column is to treat it as part of your release pipeline, not an afterthought.
When you add a new column, you must clarify its default state. Decide if it allows null. Decide if it needs a default value. This choice defines whether your migration is safe in high-traffic systems. A blocking migration on a large table will halt requests. A poorly planned default will cascade into data corruption.
Run migrations in stages. First, add the new column with nulls allowed. Then backfill data in small batches. After the backfill finishes, enforce constraints and non-null requirements. This reduces lock times and avoids table scans during peak load. Experienced teams also add feature flags to control when new code starts writing to the column. This creates a safe rollout path and lets you revert fast if something breaks.