The migration script failed. The error was clear: “column does not exist.” You need a new column, and you need it without losing data, blocking queries, or slowing deployment.
Adding a new column to a database table seems simple, but in production systems the wrong approach can lock tables, block writes, and cause downtime. The safest method depends on the database engine, the size of the table, and the traffic hitting it.
In PostgreSQL, you can add most new columns fast with ALTER TABLE ... ADD COLUMN. If the column has no default and allows nulls, this command is nearly instant — it only updates metadata. The problems start when you add a default value, apply a non-null constraint, or populate data during the migration. For large tables, that triggers a rewrite and a full table lock. The fix is to add the column as nullable, backfill in small batches with UPDATE ... WHERE, and then apply constraints after the data is populated.
In MySQL, ALTER TABLE often triggers a table copy, which is disruptive for big datasets. Use ALGORITHM=INPLACE or tools like pt-online-schema-change to add a new column without stopping writes. With MySQL 8+, some operations can be instant, but only with supported column types and without defaults that require rewriting data.