The query hit the table like a shot, but the schema didn’t care. You need a new column.
Databases evolve. Requirements shift. What starts as clean design grows into a living system. Adding a new column is not just a schema change—it’s a decision about data integrity, performance, and how the future will read and write your records. Done right, it’s seamless. Done wrong, it’s downtime and corrupted history.
First, define the column with precision. Choose the smallest data type that fits the need—VARCHAR(100) instead of TEXT if bounds are known, INT over BIGINT if values stay below limits. Smaller types reduce storage, memory footprint, and index size. Decide if the column allows NULL or needs a default value to avoid breaking existing inserts.
Next, evaluate indexing. A new column that becomes part of queries may require a new index. But indexes slow writes and consume disk. Benchmark both read and write paths before committing. Review whether the column belongs in primary indexes or needs its own secondary index. Avoid adding indexes based on intuition alone; support decisions with actual query metrics.