Adding a new column sounds simple, but the way you do it can decide whether your service stays live or grinds under load. Schema changes are not just about ALTER TABLE new_column ADD ...; they’re about precision, downtime strategy, and compatibility with existing queries. The wrong approach can lock tables, block writes, or force a costly rollback.
When you add a new column in production, think in phases:
1. Plan the schema change.
Check how large the table is and how your database engine handles ALTER TABLE. Some engines make metadata-only changes for nullable columns with defaults. Others rewrite the entire table. Read the engine’s documentation for exact behavior.
2. Add the column in a safe form.
For PostgreSQL, adding a nullable column without a default is fast. For MySQL, size matters — test it on a clone. Avoid non-null defaults that force table rewrites until you are ready to backfill.
3. Backfill in controlled batches.
Run background jobs to update rows without locking the table for seconds or minutes at a time. Use rate limits to keep replication lag under control.