The query punched back an exception. The migration failed. You knew why the second you saw the schema: there was no new column.
Adding a new column sounds simple. In production, it can be dangerous. Schema changes alter the shape of your data. A single ALTER TABLE can block writes, lock rows, or spike CPU. The wrong approach pushes latency through the roof.
The safest way to add a new column starts with clarity on the column definition. Decide the name, data type, nullability, and default value with precision. In high-load systems, default values that require backfilling can lock the table for minutes or hours. Use NULL defaults first, backfill in controlled batches, then enforce NOT NULL if needed.
In MySQL, ALTER TABLE is often blocking unless you use tools like pt-online-schema-change or native ALGORITHM=INPLACE / ALGORITHM=INSTANT where supported. PostgreSQL handles many ADD COLUMN cases instantly if defaults are not involved. For columns with computed defaults or generated values, consider database-native computed columns or materialized views instead.