Adding a new column sounds simple. In production, it can be the most dangerous change you make this week. Schema migrations can block writes, lock tables, and force downtime if handled poorly. The difference between seamless deployment and an outage comes down to process.
In SQL databases, a new column can be added with an ALTER TABLE statement. But the execution plan matters. On small tables, this is instant. On large, high-traffic tables, adding a column may trigger a full table rewrite. That means table-wide locks, delayed queries, and angry monitoring alerts.
For relational databases like PostgreSQL or MySQL, the safest pattern is to add nullable columns first. Avoid adding non-null columns with defaults in one step; instead, add the column nullable, backfill data in batches, and then enforce constraints after the migration. This prevents full table locks while the data is being written.
On distributed databases, consider whether the new column affects indexing or sharding keys. Adding a column that changes your partitioning logic can create cascading performance issues. Always benchmark on a staging environment with production-like scale.