Adding a new column sounds simple. It is not. In production systems with live traffic, schema changes are dangerous. A poorly planned ALTER TABLE can lock rows, block writes, and trigger cascading failures. A new column can break ORM assumptions, API contracts, and data pipelines if deployed recklessly.
The core challenge is control. You must choose the right migration strategy for your database engine and workload. For MySQL, tools like pt-online-schema-change or gh-ost can add a column without locking the table. For PostgreSQL, some new column additions are fast if they include no default value or constraint, but adding defaults to large tables can still require a full table rewrite.
The safest process begins with versioned migrations in source control. Always deploy schema changes in phases. First, add the new column as nullable, without constraints. Then backfill the data in small batches. Next, roll out code to read from and write to the new column. Once the entire application uses it, set constraints or make it non-nullable in a final migration.
Testing is critical. Run the migration on a staging environment with production-like data volumes. Monitor query performance during the change. Watch for replication lag. Track how fast the backfill jobs run.