Understanding and reducing database query load in WordPress

Every time someone visits a page on your WordPress site, the server runs a series of database queries to build that page. This guide explains how to identify what is causing high query counts and what you can do to bring them down.

Every time someone visits a page on your WordPress site, the server runs a series of database queries to build that page. On a busy or poorly optimised site, a single page load can trigger hundreds of queries, slowing page generation and pushing your account towards its CloudLinux resource limits.

Why query load matters on shared hosting

On shared hosting, each account runs inside a CloudLinux container with defined CPU and memory limits. A high query count means more time spent waiting for the database, which translates directly into slower page loads and higher CPU usage. If your account regularly hits those limits, WordPress will feel sluggish for visitors and you may see resource warnings in cPanel. You can read more about how those limits work in Understanding Resource Usage in cPanel.

Common causes of high query counts

Poorly coded or excessive plugins. Every active plugin can add its own queries to every page load. A site with 40 plugins active is almost always running far more queries than it needs to.
The N+1 problem in themes and plugins. This happens when code runs a query inside a loop - for example, fetching the author details for each post individually rather than in a single query. Ten posts becomes eleven queries; a hundred posts becomes a hundred and one. The result is a query count that grows with your content.
No caching layer. Without a cache, every single request hits the database fresh. A page that gets a hundred visits an hour runs its full set of queries a hundred times.
Large or unoptimised tables. WordPress stores a post revision every time you save a draft. Over time, a busy site accumulates thousands of revisions, expired transients, and bloated auto-loaded options - all of which slow down queries even when the query count itself looks reasonable.

Installing and using Query Monitor

Query Monitor is a free plugin that shows you exactly what is happening with your database on every page load. Install it from the WordPress plugin directory in the usual way.

Query Monitor is safe to leave active during your investigation. It only shows its output to logged-in administrators, so visitors are not affected. Once you have finished diagnosing, you can deactivate it or leave it in place for ongoing monitoring - just avoid leaving it active on high-traffic production sites indefinitely, as it does add a small overhead.

Once active, a toolbar menu appears at the top of every page when you are logged in. Click Query Monitor and then open the Queries tab.

What the database panel shows

Total query count and total time. These headline figures tell you immediately whether you have a problem. A well-optimised page typically runs fewer than 50 queries in under 50 milliseconds. Much higher than that and it is worth investigating.
Slow queries. Query Monitor flags any query that takes longer than a threshold you can configure. A single slow query can hold up the entire page.
Duplicate queries. This is often the quickest win. The duplicates view shows you queries that are being run more than once with identical parameters - a classic sign of the N+1 problem or a plugin fetching the same data repeatedly.
The caller column. Next to each query, Query Monitor shows you which plugin, theme file, or WordPress core function triggered it. This is how you identify which component is responsible for the bulk of your query load.

Start with the duplicates view. If you see the same query appearing dozens of times, the caller column will tell you exactly which plugin or theme function to investigate first.

Practical steps to reduce query load

Deactivate and test plugins one by one

Plugins are the most common source of excessive queries. The fastest way to find the offender is to deactivate them one at a time and reload the page in Query Monitor after each change, watching the total query count.

Before you start, use WP Toolkit's staging environment to test on a copy of your site rather than the live one. This means visitors are not affected while you experiment, and you can push your changes live once you are satisfied.

For a broader approach to auditing plugins, see Managing and auditing WordPress plugins for performance.

Enable object caching with Redis

WordPress has a built-in object cache, but by default it only lasts for the duration of a single request. Once the page has been served, the cache is discarded and the same queries run again on the next request.

A persistent object cache stores the results in memory between requests. Redis is the recommended backend for this. When a query has already been run and its result cached, WordPress retrieves the cached value from Redis instead of hitting the database again - often reducing query times to fractions of a millisecond.

To connect Redis to WordPress, follow our guide: How to integrate Redis into WordPress. You will need to enable Redis in cPanel first, which is covered in How to set up Redis in cPanel.

Do not confuse the persistent object cache with WordPress's default in-memory cache. Without Redis (or another persistent backend such as Memcached), the object cache only helps within a single page load - it does nothing to reduce repeated queries across multiple requests.

Use LiteSpeed Cache for full-page caching

Object caching reduces the cost of individual queries, but full-page caching goes further: it serves a pre-built HTML copy of the page directly, bypassing PHP and the database entirely for repeat requests.

LiteSpeed Cache is already built into our hosting stack and is the recommended full-page cache for WordPress on Kualo. Once configured, cached pages are served without touching the database at all, which dramatically reduces query load under traffic. See Configuring LiteSpeed Cache with WordPress for a full setup walkthrough.

Clean up the database

A bloated database slows queries even when the query count is low. The three main sources of bloat are:

Post revisions. WordPress saves a new revision every time you update a post or page. A site that has been running for a few years can have tens of thousands of revisions.
Expired transients. Transients are temporary values stored in the database by plugins. They are supposed to expire and be deleted automatically, but this does not always happen cleanly.
Auto-loaded options. WordPress loads certain options on every single page request. Plugins sometimes add large amounts of data to this auto-load set, slowing every page load regardless of what it contains.

Plugins such as WP-Optimize or Advanced Database Cleaner can remove all three categories safely.

Cleaning auto-loaded options carelessly can break plugins that depend on the data stored there. Always back up your WordPress site with WP Toolkit before running any database cleanup, and review what the plugin intends to remove before confirming.

You can also inspect and run optimisation queries directly in phpMyAdmin if you are comfortable doing so. See Becoming familiar with databases in phpMyAdmin and How to use the MySQL Optimize tool for guidance.

Limit post revisions in wp-config.php

You can cap the number of revisions WordPress keeps per post by adding a constant to your wp-config.php file. Open the file in cPanel's File Manager or via FTP and add the following line before the /* That's all, stop editing! */ comment:

define( 'WP_POST_REVISIONS', 5 );

This tells WordPress to keep a maximum of five revisions per post going forward. You can set it to false to disable revisions entirely, or to any integer that suits your workflow.

This setting only affects revisions created after you add it. It does not remove the thousands of revisions already in your database. Run a database cleanup as described above to remove the existing ones.

When to contact us

If Query Monitor shows reasonable query counts but individual queries are taking a long time, the first step is to look more closely at what those queries are doing. We have tools that can help you analyse slow queries and understand exactly why they are slow - open a support ticket and share the slow query details from Query Monitor, and we can investigate and advise.

For deeper PHP-level profiling - for example, to pinpoint a slow function call that is generating an expensive query - see Profiling slow PHP requests with Xdebug.

It is also worth checking whether your account is running low on CPU or memory at the time queries feel slow. Resource pressure can make otherwise reasonable queries appear sluggish. See Understanding Resource Usage in cPanel for guidance on reading your usage data, and How to use resource boosts in cPanel if you need a short-term increase while you optimise. The focus here is on making your site as efficient as possible first - resource limits are rarely the root cause when query load itself is high.