The migration failed on the last step. The log showed one line: ERROR: column does not exist. You knew the fix before the page finished loading—add a new column. Simple in theory. Painful in production.
Adding a new column to a database table is a common task, yet the details matter. Execution time, locking behavior, and backward compatibility can make or break a deploy. In PostgreSQL, ALTER TABLE ADD COLUMN runs fast if you define a nullable column without a default. In MySQL, the operation may lock the table, halting writes. In large datasets, both can cause downtime if run without planning.
Plan the migration in three steps. First, check the schema and usage. Adding a new column in the wrong place or with the wrong type may require a costly rewrite later. Second, decide on defaults. Adding a default with a NOT NULL constraint can rewrite the whole table. Instead, add the column as nullable, backfill in small batches, then enforce constraints in a later migration. Third, design application code to handle the presence or absence of the column during rollout. This prevents broken queries in a partial deploy.