The build stalled. Everyone stared at the console. The schema migration failed because the database needed a new column.
Adding a new column sounds trivial. In production systems, it can trigger downtime, lock tables, or break code paths you didn’t know depended on the old schema. The goal is to deploy without blocking reads or writes, without racing migrations, and without unexpected nulls destroying queries.
Plan the new column before touching the database. Define the column name, type, nullability, and default. For large datasets, avoid ALTER TABLE ... ADD COLUMN if it will lock the table. Use an online schema change tool or your database’s built-in non-blocking alter command. In PostgreSQL, adding a nullable column without a default is usually instant. In MySQL, consider tools like gh-ost or pt-online-schema-change for safe migrations.
Stage the change in three steps. First, create the new column in a way that does not block operations. Second, backfill data in batches to avoid high load or transaction timeouts. Third, update application code to begin reading and writing to the new column. Only after verifying production reads do you remove old fields or related logic.