Skip to content

The Fastest Query Is the One You Never Execute

The dashboards looked healthy, yet users said the app felt slow. The culprit wasn't an expensive query — it was the same query running over and over again.

By 2 min read
  • Production Lessons
  • Caching
  • Performance Engineering
  • System Design
  • Software Architecture

A production incident once taught me a lesson I'll never forget.

  • The dashboard looked healthy.
  • CPU usage was normal.
  • Memory was stable.
  • The database wasn't overloaded.

Yet users kept reporting that the application felt slow.

The Fastest Query Is the One You Never Execute

After tracing a few requests, the problem became obvious. The application wasn't running expensive queries. It was running the same query over and over again.

Every request asked for data that had already been fetched seconds earlier. Nothing was technically broken.

The system was simply doing unnecessary work. That's when I realized something that changed how I think about performance.

Most performance problems aren't caused by slow code. They're caused by repeated work.

When a request arrives, ask yourself:

  • Do I already have this data?
  • Has it actually changed?
  • Does this request need the database?
  • Can this response be safely reused?

Those questions often matter more than adding another database index.

Great production systems don't just execute queries efficiently. They avoid executing queries that don't need to happen.

That's why caching, request deduplication, and precomputed results have such a huge impact at scale.

Not because databases are slow. But because every unnecessary query competes with the ones that actually matter.

One lesson I carry into every architecture discussion is this: Optimization isn't always about making systems work faster. Sometimes it's about making them work less.

What's the biggest performance improvement you've seen that came from removing work instead of optimizing it?

Keep reading