A new column sounds simple, but in live systems it can become a bottleneck that kills performance if handled wrong. Schema changes are high impact. Altering tables in production means locking rows, invalidating caches, and syncing application code to match. The wrong approach forces full table rewrites, driving CPU and I/O to their limits.
Modern databases like PostgreSQL, MySQL, and MariaDB offer faster paths. Adding a new nullable column with a default null is usually instant. Adding one with a default value can still be instant in newer versions, but older versions will still rewrite the table. For massive datasets, this difference is critical. Always check the database version and review the migration plan before running ALTER TABLE.
Schema migrations should be idempotent and tested. Break the change into steps: create the new column without defaults or constraints first. Backfill data in small batches under load. Add constraints only after verifying consistency. This keeps services responsive while the schema evolves underneath.