The 20% of Queries Driving Most of Your Database Load

Database load is rarely spread evenly. When the database starts straining, the instinct is to treat it as a whole-system problem: the database is slow, so the database needs more capacity. But pull apart where the time actually goes and the picture is usually lopsided. A small number of query patterns tend to account for a disproportionate share of executions and database load. The rest barely register.

The trouble is that the metrics most teams watch are built to hide this. Average query time, total QPS, overall CPU utilization, these roll everything into a single number, and an average is exactly the wrong tool for finding a skewed distribution. A handful of high-volume query patterns can sit comfortably inside a healthy-looking average while quietly consuming most of the machine. The dashboard looks fine right up until it doesn't.

This skew shows up often enough to be worth expecting. Call it a Pareto-like pattern: a small fraction of query patterns frequently drives the majority of the work. The exact ratio varies by workload, but the lopsidedness is the rule, not the exception. And it changes what the right response is.

Here's why that matters, and what acting on it looks like:

• Aggregate metrics point you at the wrong fix. A high average latency tells you something is slow, not what. Scaling the whole system treats every query as equally guilty when a few are doing most of the work.
• Scaling the entire database is expensive when the problem is narrow. A bigger instance or another replica adds capacity for all your queries, including the majority that weren't driving the load. You pay to scale the whole thing to solve for a sliver of it.
• The fix depends on which patterns they are. Once you know the heavy hitters, the options open up: an index, a query rewrite, a caching layer for the repeated reads, or a replica if the load really is broad.
• Replicas are one answer, not the default one. Adding a replica can reduce pressure on the primary, but it doesn't reduce the total amount of work being done. When a few repeated reads dominate, you've copied the expensive work onto another machine instead of removing it.

The throughline is that you can't fix what you can't see, and the standard metrics are built to average the problem away. The first move is finding the query patterns doing the most work. Readyset RDST connects to your Postgres or MySQL database and identifies the query patterns responsible for the most load, so you can see the heavy hitters before you decide how to handle them.

🔍 What We're Watching in the Database Ecosystem

Why Enterprise AI Is Hitting an Infrastructure Wall in 2026

A look at how AI workloads are straining infrastructure that was never designed for them, with GPU scarcity, egress costs, and contention for shared resources all colliding at once. The throughline that matters for database teams: high-concurrency transactional traffic, big analytical scans, and low-latency AI retrieval are increasingly fighting for the same resources, and most setups weren't built for that mix. A useful frame for anyone watching their database do more jobs than it was provisioned for.

The MySQL Community Launches the OurSQL Foundation

At Percona's 20th anniversary in Mountain View, a group including Percona, PlanetScale, PingCAP, and Alibaba Cloud launched the OurSQL Foundation, a vendor-neutral nonprofit meant to give the MySQL community a more formal, independent voice. Notably, it's being positioned not as an anti-Oracle move but as a parallel community effort, with Oracle invited to participate, at a moment when Oracle has been signaling renewed investment in MySQL, including vector search for AI workloads.

In Case You Missed It

Want more between issues? We post regularly on LinkedIn: query breakdowns, benchmark numbers, and notes on real MySQL and Postgres performance.

Know a database aficionado who'd appreciate this? Forward it their way.