Adding a new column sounds simple. It is not. In a live system, every schema change carries risk—lock contention, long-running migrations, broken queries, and silent data loss. A single ALTER TABLE in Postgres can freeze writes if it rewrites the whole table. MySQL can behave differently across storage engines. Even fast DDL operations cause replication lag you didn’t plan for.
The right approach starts with intent. Decide if the new column is nullable or has a default. Nullable columns are faster to add. Defaults with constant values, applied without table rewrite, keep downtime near zero. Test these changes against realistic data volumes. Use staging to profile run time under peak load.
Version your schema changes. Deploy the new column first. Code in production should handle both the old and new structure. Backfill in small batches if needed. Only once the data is ready should you make the column non-null or shift reads and writes to it.