The table was broken. The data didn’t fit. You needed a new column, and you needed it now.
Adding a new column sounds simple. In practice, it’s where schema design, migration strategy, and production risk collide. Whether in PostgreSQL, MySQL, or distributed databases like CockroachDB, the wrong approach can lock tables, stall queries, or break code in production. A new column in the wrong place or at the wrong time can wreck your deployment schedule.
First, choose the column type with precision. Mismatched data types will trigger implicit casts, slow reads, and amplify storage costs. Decide on nullable vs. not-null before writing the migration. Switching to NOT NULL later on large datasets can be expensive and require downtime.
Second, design your schema migration to be safe under load. In PostgreSQL, ALTER TABLE ADD COLUMN with a default value rewrites the entire table. On large tables, this can hold locks for minutes or hours. Instead, add the new column with no default, backfill in batches, then set the default in a separate step. This pattern avoids long locks while ensuring data integrity.