The fix was simple: add a new column.
Creating a new column is more than typing an ALTER TABLE command. It’s a choice that affects queries, performance, indexing, and the way a system grows over time. Whether you’re working in PostgreSQL, MySQL, or a distributed data store, the smallest schema change can ripple across every query and service that depends on it.
In SQL, adding a column often starts with:
ALTER TABLE orders ADD COLUMN delivery_date DATE;
This runs fast on small tables. On a billion rows, it can lock writes, stall pipelines, and trigger costly migrations. Planning a new column means understanding the storage engine, transaction locks, and how constraints or defaults will hit CPU and disk I/O.
A nullable new column is safest for live systems. Adding a column with a default non-null value can rewrite every row, ballooning operational costs. In some cloud-managed databases, adding a new column to a large table may still trigger a full table rewrite if you’re not careful. Test migrations on a clone before touching production.