The database froze. A single query stalled the system, and logs pointed to one missing piece — a new column.
Adding a new column is routine, but in production it’s never trivial. Migrations can lock tables, block writes, and trigger costly downtime. The right process keeps data consistent, queries fast, and the API in sync. Skip those steps and you risk breaking the application mid-request.
A new column starts in the schema. Define the type, default values, and constraints with exact syntax for your database engine. In PostgreSQL, ALTER TABLE is direct but can lock large tables. MySQL’s ALTER TABLE can cause similar blocking without ONLINE modifiers. For high-traffic systems, break the migration into phases: create the column without constraints, backfill in small batches, then enforce constraints once data is ready.
Application code must handle both old and new states during rollout. Read paths should not fail if the column is null or missing in replicas. Write paths should tolerate delayed migrations across shards or regions. Test queries against staging datasets that match production scale to catch slow scans or misaligned indexes.