The schema was locked. The product team wanted change. The database needed a new column.
Adding a new column sounds simple. It is not. In production, every schema change is a live operation. You balance speed against data safety, and every choice has trade-offs. A careless ALTER TABLE can block writes, spike latency, or even lock out users.
The first step is understanding the database engine. PostgreSQL, MySQL, and SQLite each handle column additions differently. PostgreSQL can add a nullable column with a default almost instantly, but populating existing rows with non-null values forces a full table rewrite. MySQL may block reads and writes depending on storage engine and configuration. Cloud-managed databases sometimes simulate schema changes and replay traffic, creating the illusion of zero downtime.
The safest pattern for a new column is to break the change into phases. First, deploy code that can handle both the old and new schema. Then add the column in a way that avoids long locks—often by creating it as nullable without a default, then backfilling data in small batches. Finally, once data is complete, apply constraints and defaults in a separate migration.