The migration failed. The logs said nothing. The database had changed, but the table no longer matched the schema in source control. A single missing new column had stalled deployment across three services.
Adding a new column is routine, but it is never trivial. In modern systems, a schema update can cascade through APIs, jobs, and stored procedures. The choice between altering in-place or creating a new table can affect latency, locking, and backward compatibility. The wrong approach can block queries or corrupt data in production.
To add a new column safely, start by defining its purpose and constraints. Decide if the column can be nullable at first, then made non-null after backfilling. For high-traffic tables, use online schema change tools to avoid locking. Always test migrations against a copy of production data. This will reveal performance issues that small datasets hide.