The database was ready to ship, but the schema wasn’t. A single requirement stopped the release: you needed a new column.
Adding a new column should be fast, safe, and obvious. Yet in many systems, it’s slow, risky, and surrounded by migration pitfalls. The stakes rise when the database is in production, traffic is live, and every schema alteration could lock tables or trigger downtime.
A new column changes more than just structure. It can impact query plans, alter indexes, and even change how the ORM behaves. Good engineering practice demands you understand what the column will store, how it will be queried, and whether it should be nullable. Those decisions determine the performance profile of your application weeks or years from now.
In relational databases, ALTER TABLE ... ADD COLUMN is the command of choice. In databases like Postgres, adding a column with a default value can rewrite the table, which may block reads and writes if the dataset is large. Adding it without a default and then backfilling in small batches avoids downtime. If you need the column to be indexed, create the index in a separate operation to prevent long-running locks.