The migration was almost done when someone noticed the missing field. The fix was simple: add a new column. The execution was not.
Adding a new column in a production database sounds small. It can be the most dangerous kind of change. If it blocks writes or forces a full table rewrite, you risk downtime. Even with modern cloud databases, the wrong DDL locks can cascade into outages.
The safest path starts with understanding your database engine. In PostgreSQL, adding a nullable column without a default is instant. Adding one with a non-null default rewrites the table. In MySQL, behavior depends on the storage engine. With InnoDB, older versions still lock the table for some changes. New releases use fast DDL for more scenarios, but only if your syntax is exact.
For large tables, use an online schema change tool. In PostgreSQL, use ALTER TABLE ... ADD COLUMN with no default, then backfill in small batches. In MySQL or MariaDB, consider pt-online-schema-change or gh-ost to add the new column asynchronously. This avoids locking the full table at once.