Adding a new column is one of the most common schema changes, but it is also one of the most dangerous if handled without care. A poorly executed migration can lock a production database, slow queries to a crawl, or cause downtime that costs both revenue and trust. The goal is to expand the schema without breaking read or write operations.
Start with the migration plan. Determine whether the new column needs a default value, if it must be non-null, and how it will interact with existing indexes. For large datasets, adding a non-null column with a default can trigger a full table rewrite, spiking I/O and saturating CPU. The safer approach is often to add the column as nullable, backfill in batches, and then apply constraints in a separate step.
Use rolling deployments where possible. If application code and database schema need to change together, deploy in phases. Release code that can handle both the old and new schema before the actual migration. This prevents exceptions during the switch. Avoid long-running locks by using ALTER TABLE ... ADD COLUMN in a controlled window, or with tools such as pt-online-schema-change for MySQL or ADD COLUMN IF NOT EXISTS in PostgreSQL.