The build was almost complete when the data model broke. The schema needed a new column.
A new column is one of the most common schema changes in any production database. It sounds trivial. It is not. The way you add it can decide if your system stays fast or collapses under load. When you add a column, you change the shape of your data. The database must rewrite internal structures. In large tables, this can lock writes, delay queries, and trigger full-table rewrites.
Before adding a new column, you must check the table size, the database engine, and the migration strategy. In PostgreSQL, adding a column with a default value before version 11 rewrites the entire table. In MySQL, depending on the storage engine, it may block reads. For distributed databases, adding schema changes often requires coordination across nodes and versioned deployments.
The best practice is to add new columns in a non-blocking way. First, create the column with no default and allow nulls. Then backfill data in small batches. Once the data load is complete, apply constraints and defaults in a separate step. This avoids downtime and reduces migration risk. Plan indexing last, after you have measured query performance against live traffic.