Adding a new column to a production database sounds simple. It isn’t. Schema changes can lock tables, slow queries, and break downstream systems if handled without care. The details matter: column type, nullability, default values, indexing strategy, and data migration paths all decide whether the change succeeds or destroys performance.
First, assess the impact. Run an explain plan on queries that touch the target table. If the table is large, adding a non-nullable column with a default can force a full rewrite of every row. On PostgreSQL, that means blocking writes until completion. On MySQL, behavior depends on the storage engine, but may still trigger a costly table copy. Plan to make the column nullable at first, then backfill data asynchronously.
Second, think about compatibility. Application code must handle the presence and absence of data in the new column until migration is complete. This requires careful coordination between database deploy scripts and service releases. Add feature flags so you can control rollout without risking downtime.