The query hit the database like a punch, but the data wasn’t there. You need a new column.
Adding a new column is routine until it isn’t. In production, it can lock tables, break queries, and stall releases. Done wrong, it slows every read and write. Done right, it’s invisible to the users and safe for uptime.
A new column changes the schema. In SQL, you use ALTER TABLE with the ADD COLUMN clause. For example:
ALTER TABLE orders
ADD COLUMN processed_at TIMESTAMP NULL;
This creates the column without touching existing rows. But depending on the database engine—PostgreSQL, MySQL, or SQLite—the cost can be different. Large tables, foreign keys, indexes, and default values can all turn a schema change into hours of downtime.
Before adding a new column, measure. Check the table size. Check concurrent load. If possible, apply the change in a transaction that can roll back. Avoid non-null defaults unless required—they force a rewrite of every row. When you need a default, add the column first, then backfill in small batches.