The query hit the database like a hammer, but the schema refused to bend. You need a new column. Not later. Now.
Adding a new column to a table sounds simple, but the wrong approach can crush performance or lock writes at scale. In fast-moving systems, schema changes must be planned, measured, and deployed with precision.
A new column alters the table definition. In many SQL databases, this can trigger a table rewrite, block access, or impact replication lag. For small tables, ALTER TABLE ADD COLUMN is harmless. For tables with millions or billions of rows, it can be dangerous if executed without care.
Before adding the column, confirm whether it needs a default value. Adding a NOT NULL column with a default forces the database to fill every existing row during the migration, which can cause long locks. If the column can start as NULL, add it without a default, then backfill in batches.
Use transactional DDL if your database supports it. In PostgreSQL, adding a nullable column without a default is nearly instant. Backfill in controlled chunks, using indexed selects to avoid full-table scans. Monitor query performance after each batch.