Adding a new column is one of the most common database changes. It looks simple. It is not. Done wrong, it can lock a table, block writes, and slow every query that touches it. Done right, it is a fast, safe, reversible operation. The difference is in how you plan, execute, and verify the change.
First, know your database system. In PostgreSQL, ALTER TABLE ADD COLUMN is fast if you define it without a default value. The column is added to the metadata, and existing rows are untouched. Set the default later with UPDATE in small batches. If you set the default during the ALTER TABLE, the system will rewrite the whole table, which can be slow and risky on large datasets.
In MySQL, the story is more complex. Adding a column often triggers a table copy. On large tables, this is expensive. Use ALGORITHM=INPLACE when possible, but test on staging to confirm behavior. MySQL version changes can alter how the command runs. Always confirm with SHOW PROCESSLIST or performance schema metrics in a safe environment before production.
Schema migrations need discipline. Wrap them in version control. Use a migration tool that tracks state. Run migrations in maintenance windows if you cannot confirm they are online-safe. Monitor impact as soon as the migration begins—watch replication lag, cache hit ratios, and query latency.