The migration was going fine until the schema needed a new column.
Adding a new column can be simple or it can bring down a system. The difference lies in how you plan, execute, and test. A poorly timed schema change locks tables, slows queries, and risks data loss. A well-executed one goes live without anyone noticing.
First, decide if the new column is necessary. Check if the data already exists in another form. Redundant columns create maintenance debt and confusion in queries. If it’s needed, define the column type with precision. Choosing the wrong type now means years of inefficient storage and rewrites later.
For production databases, always add a new column in a way that keeps writes and reads consistent. In systems like PostgreSQL, adding a nullable column without a default is often instant. But adding with a default value can trigger a table rewrite—dangerous for large datasets. Split the change: add it first as nullable, then backfill with an UPDATE in controlled batches. Only set the default at the end.