New column migrations can make or break a release. One wrong move and you lock up the database, burn CPU, and block deploys. Done right, they are fast, safe, and invisible to the rest of the system.
A new column sounds simple—just add it. In production, the reality is harder. Schema changes can trigger full table rewrites, impact indexing, and introduce downtime. The choice of data type, default values, and nullability can decide whether your migration takes seconds or hours.
The safest way to add a new column is to run migrations in small, reversible steps. Create the column without a default that forces a table rewrite. Populate it in batches, backfilled without locking large sections of data. Add indexes in a separate migration to avoid load spikes. Then enforce constraints only when data is clean.
SQL databases like PostgreSQL and MySQL each have their own rules. PostgreSQL can add a nullable column instantly, but adding a column with a non-null default rewrites the table. MySQL may block writes during certain ALTER TABLE operations unless you use online DDL features. Always check the execution plan before running migrations against production.