The migration halted when the schema failed. The logs showed a missing column. The fix was simple: add a new column. The challenge was doing it without downtime, data loss, or corrupted queries.
A new column may look small in a migration script. In production, it can break critical paths. You must plan the change so existing reads and writes still work. That means making the migration in steps. First, add the column as nullable. Then deploy the code that writes to it. Backfill the data in batches. Finally, make it required if needed.
Adding a new column in PostgreSQL is usually fast if it includes no default for existing rows. In MySQL, the speed depends on the table engine and size. For high-traffic systems, run schema changes in a way that does not lock the table for long periods. Online schema change tools like pt-online-schema-change or gh-ost can help.
When you add a new column, review indexes. Adding it to an index changes query performance and storage. Sometimes it is better to keep it unindexed until you see how it’s used in queries. Monitor slow query logs after release.