Adding a new column should be simple. In production, it’s not. Schema changes touch live data, lock tables, and block reads or writes. A poorly planned migration can stall an application under load. Even a single ALTER TABLE statement can cause downtime if it’s not executed with the right strategy.
A new column is more than extra storage. It changes the shape of your data. You need to define the column type, default values, constraints, indexing, and backfill strategy. For large datasets, this must be done incrementally to avoid blocking traffic. Online schema changes, shadow writes, or backfill jobs are common patterns for production-safe deployment.
Start with the migration plan. Add the column in a way that is backward-compatible. Write application code that handles both old and new schemas during rollout. Avoid NOT NULL constraints until after data is backfilled. If you need an index on the new column, build it in a separate operation to distribute load. Always measure migration time in staging with realistic dataset sizes before touching production.