The migration froze halfway through. The logs showed an error: missing column. You scanned the schema, but the column didn’t exist yet. The fix was clear—add a new column—but the way you do it determines whether the service stays up or burns down.
Adding a new column is simple in theory. In production, it’s never just ALTER TABLE. Schema changes, especially new columns, can lock tables, block writes, and cripple performance. The goal is to make the change without downtime and without corrupting data.
First, audit the impacted queries. A new column shouldn’t break existing reads or writes. Add it in a way that defaults work for old code while preparing for new logic. Use NULL or a safe default to avoid constraint failures during deployment.
Second, time the change. On large datasets, adding a new column can take seconds or hours depending on the database engine. PostgreSQL with ADD COLUMN and a default value rewrites the entire table. In MySQL, certain ALTER operations block changes. For massive tables, staged rollouts are safer.