Adding a new column is one of the most common schema changes in modern applications. It sounds simple. It can break production if handled poorly. Migrations that add columns touch schema integrity, query performance, and operational uptime. Doing it right means planning for compatibility, testing for I/O load, and deploying with zero downtime.
A new column changes the structure of a table. When that table holds millions of rows, the modification can lock writes or trigger vacuum processes. In PostgreSQL, a new column with a default value often rewrites the entire table. In MySQL, certain ALTER TABLE operations block queries until they finish. The wrong command at the wrong time can freeze services.
Best practice is to deploy the new column without locking. In PostgreSQL, adding a nullable column runs instantly. Setting the default later with ALTER COLUMN avoids the full rewrite. In MySQL, use ALGORITHM=INPLACE when possible. Always check how your engine executes the statement before running it in production.
Indexing the new column needs its own migration. Create the column first. Populate values. Then build the index in a controlled process. Splitting changes reduces risk. Monitor query plans after introduction to catch altered execution paths.