· 1 min read
Why Fast Queries Become Slow
Query performance rarely changes overnight. More often, the data simply outgrows the assumptions the query was built on.
A database query rarely becomes slow overnight.
More often, it starts as a perfectly reasonable query against a relatively small dataset. It gets deployed, performs well for months, and quietly survives multiple feature releases. Eventually, someone notices that an endpoint which used to respond in a few milliseconds now consistently takes hundreds.
The query itself hasn’t changed.
The data has.
As datasets grow, assumptions that were once true slowly stop being true. An index that used to filter most rows becomes far less selective. A join that once touched a few thousand records suddenly processes millions. The optimizer chooses a different execution plan because the statistics tell a different story than they did six months ago.
The first instinct is often to rewrite the SQL.
Sometimes that’s necessary, but more often the better question is why the database chose the execution plan it did. Looking at estimated versus actual row counts, identifying expensive scans, and understanding where time is really spent usually provides far more insight than immediately trying to produce a “better” query.
Performance tuning isn’t about writing clever SQL.
It’s about understanding how your data evolves over time and making sure your indexes, statistics, and query patterns evolve with it.