The schema was wrong, and everyone knew it. A new column had to be added, but downtime was not an option. Data was live, requests were constant, and the migration needed to be safe, fast, and reversible.
Adding a new column sounds simple until production is involved. Schema changes can lock tables, block reads, and bring down APIs if done carelessly. The key is to design the change so it works in phases. First, add the column with a default or nullable value to avoid expensive rewrites. Then backfill data in small batches to prevent latency spikes. Finally, deploy the application changes once the column is populated and indexed. Each step should be reversible.
When creating a new column in PostgreSQL or MySQL, use ALTER TABLE with care. On large datasets, this can lock writes. Options like ADD COLUMN ... DEFAULT NULL are safer. Backfill scripts should be idempotent. Use migrations that can be rolled forward or backward without risk. Keep the deployment atomic from the perspective of the application, even if the database change is gradual underneath.