The migration failed. The logs showed why: no space left to add the new column.
Adding a new column seems simple. In most systems, it is anything but. The cost depends on the database, the size of the table, and whether the schema change is blocking or non-blocking. In production, a careless ALTER TABLE can lock reads and writes, block transactions, and stall the entire application.
For small tables, a new column with a default value runs quickly. Large, high-traffic tables are different. Many relational databases must rewrite the entire table to store the new field. This can mean hours or days of downtime without proper planning. Some platforms offer online schema changes. Others require workarounds like shadow tables, phased rollouts, or adding a nullable column first, then backfilling data in smaller batches.
Indexing a new column can be even more dangerous. An index build on a multi-billion-record table will consume significant I/O and CPU. Without throttling or concurrent options, you risk performance collapse under load. The safest approach is to test the change on a clone of production data, measure the effects, and schedule the operation during low-traffic windows.