The query was fast, but the table was wrong. You needed one more field: a new column.
Adding a new column should be simple. In practice, it can be slow, risky, and disruptive if the dataset is large or the system is under load. Schema changes touch everything. The database must rewrite structures, update metadata, and sometimes lock tables. Bad timing can stall an entire application.
The safest approach starts with understanding the impact on the specific database engine. In PostgreSQL, a new column with a default value forces a full table rewrite. Without a default, it’s instant. In MySQL, ALTER TABLE can rebuild the table depending on the storage engine. In MongoDB, a new field can be added to documents on demand without downtime. These differences matter.
Plan the change in isolated stages. First, deploy the schema statement in a migration that does nothing expensive. For example, add a nullable column without defaults. Then backfill data in batches using application logic or background jobs. This way, the schema change is fast, and the heavy lifting is done without blocking requests.