The new column was there, waiting to change everything in your data model. One line in your migration script, and the shape of your application shifts. Done right, adding a new column is simple. Done wrong, it can grind production to a halt. You cannot afford mistakes.
A new column in a database table is not just extra space. It changes queries, indexes, performance, and even business logic. Before you run ALTER TABLE, decide on the column name, data type, default value, and nullability. Each of these affects future queries and migrations.
For relational databases, adding a new column with a default value can lock the table during write operations. On large datasets, this can cause downtime. Break the change into steps: add the column as nullable, backfill in small batches, then apply constraints. This approach also works well for zero-downtime deployments in high-traffic systems.
If your application uses an ORM, you still need to align schema changes with code changes. Mismatches between deployed code and the live schema can throw runtime errors. Roll out the schema update first. Deploy the code that uses the new column after the migration is complete and verified.