Is the database the bottleneck?

The database gets blamed first because it is the component everyone shares and the one fewest people can see into. In our reviews it is actually guilty a little over half the time, which makes "the database is slow" simultaneously the most common correct diagnosis and the most common incorrect one.

What do we look at before believing the accusation?

The sequence rarely varies. First, saturation versus latency: is the database working hard (CPU, IO, connections at limit) or merely answering slowly? A database at 20% utilization with slow responses is usually a victim: of lock contention, of a missing index turning point reads into scans, or of the network between you. Second, the connection pool, which we check before anything glamorous: a pool of 20 connections in front of 40 application instances is arithmetic pretending to be a mystery. Queueing for a connection is invisible in database metrics and shows up as "database latency" in every dashboard built by the accused's prosecutors.

Third, the query distribution. In most systems, the top five statements by total time are the entire story, and one of them was added three sprints ago with an ORM include that looked innocent in review. The fix is an index or a rewrite, not a migration project.

What would have to be true for scaling to be the answer?

Genuine saturation on a tuned workload: the top queries are as cheap as they can be, the pool is sized to reality, and the box is still out of headroom. Even then the question forks. Read saturation has a gentle answer (replicas, with the replication-lag caveats every team learns once). Write saturation has expensive answers, which is why we treat sharding as a last resort with its own briefing, and why caching, the other reflex, earns its own skeptical treatment.

It is worth saying what modern hardware does to intuitions formed a decade ago: a single well-provisioned Postgres or MySQL node in 2026 serves workloads that justified sharding projects in 2015. The industry's collective memory of "we outgrew one box" ages poorly, and buying the bigger box remains the highest engineering-ROI move in the catalog, unfashionable as it reads in a design review.

What if it truly is the database?

Then say so with a number attached: which resource, at what utilization, on which workload, and what the ceiling buys. "The database is the bottleneck at 4,000 checkouts a minute, on writes, at 85% IO" is a statement a roadmap can be built on. "The database is slow" is a mood, and moods get funded in proportion to the meeting's seniority rather than the system's need.

The pattern beneath the briefing: shared components attract blame in proportion to their opacity. The cheapest fix is often not to the database but to the visibility, so the next accusation arrives with evidence pre-attached.