Adding a new column sounds simple. In production, it can be a minefield. Schema changes in relational databases can block writes, trigger full table rewrites, and bring services down. The key is understanding how your database handles ALTER TABLE, concurrency, and rolling deploys before you run the first migration.
In PostgreSQL, adding a new column with a default can lock the whole table. To avoid downtime, create the column without the default, then backfill rows in batches, and finally set the default for future inserts. MySQL can be faster for some operations, but large tables still risk outages if the change is not online. Use tools like pt-online-schema-change or gh-ost to apply a new column with minimal locks.
A new column also has ripple effects in the codebase. Application models, serializers, caching layers, and analytics pipelines all need to be updated in sync. This means planning versioned deployments: deploy code that can read and write the new column without breaking the old flow, run the migration, then deploy the code that depends on the new data.