The database was fast, but the schema was wrong. You needed a new column, and every minute without it was bleeding time from the project.
Adding a new column should be direct. Yet in most systems, it’s a drag: schema changes in production, zero-downtime migrations, backfills, and the risk of breaking queries already in flight. It’s not just the ALTER TABLE—it’s the blast radius.
Start with clarity on the data type and constraints. A poorly chosen type will force a rewrite later. Decide if the new column needs defaults, nullability, or indexing from the start, because retrofitting those after deployment will cost far more. Test insertion and query performance in a staging environment that mirrors production scale.
If you’re adding a new column in PostgreSQL, adding a nullable column without a default is instant. But adding a not-null with default rewrites the table. For massive datasets, that’s downtime unless you deploy in phases: first add the column nullable, then backfill in batches, then add constraints.