Your WordPress Site Slows Down Over Time. The Database Is Why.

Picture this scenario, because we see it often. A solicitor's firm in Sligo, four years on the same WordPress site. The site used to load instantly. Now the office secretary is watching the homepage take six seconds, and the intake form is timing out for clients trying to submit case enquiries from their phones. The firm rings their hosting provider expecting to be told the server is overloaded.

The server is not overloaded. The database is.

This is the most common pattern we deal with on the operations side. The site was fast at launch. It got slower in small, invisible increments over two or three years. By the time anyone notices, performance has degraded enough to lose real enquiries. And the cause is almost never what the business owner expects.

The slowdown nobody warns you about

When you launch a WordPress site, nobody hands you a maintenance schedule for the database. Hosting providers do not phone you when your post revisions cross fifty thousand rows. There is no warning email when an obsolete plugin leaves four megabytes of orphaned data autoloading on every request.

The result is that the owner-operator is usually the last person to know their site is dying from the inside.

We see this pattern repeat on sites with as few as fifty pages and as many as several thousand. Three things bloat over time. The wp_options table grows beyond reasonable autoload limits. Post revisions accumulate without a ceiling. Expired transients pile up because nothing is cleaning them out.

Any one of these costs a site real response time. All three at once is the difference between a customer staying and a customer giving up.

The frustrating part is that none of this shows up in the normal symptoms a small business owner is trained to look for. The site is "up". The pages render. The contact form looks like it works. Conversions just quietly drop, and PageSpeed scores quietly slide, until somebody notices the trend three quarters in.

The wp_options autoload bomb

Every time a WordPress page loads, the database runs a query against the wp_options table to load every option marked as autoload. That is by design. Options like your site title, your active theme, and certain global settings need to be available on every request.

The problem is that plugins, especially older plugins, autoload aggressively. They store configuration data, template caches, dashboard widgets, telemetry payloads, all marked as autoload. And when a plugin is deactivated or removed, that data does not always clean up after itself.

The current WordPress guidance is clear. As detailed in the WordPress Options API documentation, autoloaded data should stay under 800 KB. Anything past 3 MB is a real problem. Past 5 MB and the site is paying a measurable penalty on every single request, particularly on shared hosting with slow disks ^[1].

Here is what that means in practice. Each request to the site has to load that autoload payload into PHP memory and unserialise it before it can do anything else. If the payload is four megabytes of orphaned Elementor data from a theme you migrated away from two years ago, the server is wasting CPU on a layout you no longer use. Every visitor pays for it. Every Google bot pays for it. The intake form on the Sligo firm's site pays for it twice, once on the form page and once on the thank-you page.

The fix is not glamorous. Identify the largest autoload entries. Disable autoload on the ones that do not need to fire on every request. Remove the orphans from deactivated plugins outright. Since WordPress 6.6, Site Health flags large autoload sizes for you ^[2]. That check did not exist three years ago, which is one reason older sites carry years of buried autoload weight that the owner was never told about.

Post revisions: a thousand copies of every page edit

By default, WordPress stores unlimited revisions of every post and page. Every time someone clicks Update, a new revision row is created. The database stores the full content of the post, not just what changed.

This sounds harmless until you put numbers on it. A site with fifty pages, each edited a hundred times over four years, will hold five thousand revisions. We have seen single pages on real business sites carry over a thousand revisions on their own ^[3]. Pruning those down to the most recent five per post can reduce the size of the wp_posts table by forty to sixty per cent.

That is not a hypothetical. That is the most common single optimisation we run on inherited sites.

So what does it mean for the business? Most front-end queries do not touch the revisions directly, but the table indexes do. As wp_posts grows, every query that scans it slows down, including the queries that build navigation menus, sitemaps, archive pages, and category listings. The query plan gets uglier. The database server uses more memory. Cache hit rates drop. And the page that lists your services drops a couple of hundred milliseconds of response time without anyone ever editing the services page.

The fix is straightforward. Set WP_POST_REVISIONS to a sensible number, typically five, in wp-config.php. Then prune existing revisions in a controlled cleanup, with a backup taken first because the operation is destructive and you cannot roll it back without one. A properly run cleanup deletes the surplus revisions, optimises the tables, and verifies the row counts before signing off.

Transients: cache that never gets thrown out

Transients are the most misunderstood thing in WordPress. They are short-lived cached values that plugins use to avoid expensive operations. A plugin that queries the Twitter API every five minutes will cache the result in a transient, and read from the transient on the next ninety-nine requests.

This is fine on a healthy site. The problem is what happens when the transient is supposed to expire.

WordPress does not have a cron job that proactively deletes expired transients. They are removed only when something next tries to read them, finds the expiry has passed, and deletes the row. As Delicious Brains explains, if a transient is set under one key, never read again, and the plugin is later deactivated or renamed, that row sits in the wp_options table forever ^[4].

On a site that has been through five plugin changes and two theme migrations, there can be tens of thousands of orphaned transient rows. Each one is small. Together they bloat the options table indexes, slow the autoload query, and make every database query against wp_options work harder than it needs to.

You can clean transients with a plugin or directly. WP-Optimize, Delete Expired Transients, and Advanced Database Cleaner all do this. WP-CLI can run the cleanup on a schedule. On a managed host, this should be running automatically without you ever knowing about it.

What managed hosting actually does about this

There is a difference between hosting that runs WordPress and hosting that operates WordPress. Most shared hosts do the first. They give you a server, install a copy of WordPress, and walk away. If your database bloats over three years, that is your problem to solve. The hosting renewal email arrives every twelve months whether the site is fast or slow.

Properly managed hosting takes the application side seriously, not just the server side. That means scheduled database maintenance, autoload monitoring, expired transient pruning, table optimisation runs, and alerts when something grows in a way that looks abnormal.

Web60's infrastructure is built on the WordOps stack with Redis object caching enabled by default. The Redis layer matters specifically for this problem. When transients hit Redis instead of wp_options, the table stays leaner because the bloat-generating writes never reach the database. Combined with scheduled maintenance and table-level monitoring, the result is a WordPress database that grows in proportion to actual business content, not in proportion to plugin churn. For a local firm running a brochure site or a small online shop, Web60's all-inclusive €60/year managed WordPress hosting on Irish infrastructure handles this layer of operational work without the owner ever having to know it is happening.

This is the unglamorous part of managed hosting. Nobody markets it because it is hard to make exciting. But it is the difference between a site that is still fast at year three and a site that needs an emergency database rescue.

For the broader picture of where database performance sits inside everything else that affects a WordPress site's speed, the complete WordPress performance guide for business owners is worth reading. Database bloat is one of a stack of issues, and image optimisation is another big one, covered separately in the article on why photos are usually the bigger performance problem.

How to verify your database is the problem

Most business owners can do a basic check themselves before anyone needs to log in at the operational level. Here is the short version.

1. Verify the Site Health screen. In WordPress admin, go to Tools, then Site Health. If autoload is over the threshold, the check flags it. This existed only in WordPress 6.6 and later, which is one reason older installs may need a manual look.
2. Audit the autoload contents. With a database tool like phpMyAdmin or a plugin like Query Monitor, list the largest entries in wp_options where autoload is set. Anything in megabytes is suspect.
3. Check the revision count. Run SELECT COUNT(*) FROM wp_posts WHERE post_type = 'revision'; against the database. If the number is shocking, it is shocking for a reason.
4. Sweep expired transients. WP-Optimize will show you the count and clear them in one operation. Do this before any other database work because it shrinks what every later step has to scan.
5. Schedule maintenance to run weekly. Either a plugin with a cron schedule, or, on a properly managed host, a server-level job that does not depend on WordPress cron working reliably.

Reviewing our incident log from last month, the most common pattern was sites where step one was never run because nobody knew Site Health existed. A check that takes thirty seconds.

The honest limits of all this

I will admit a mistake we made early on. We had a customer site that was bloating quickly and we treated it as a database-only problem. We pruned revisions, cleaned transients, optimised the autoload. The site got faster for a month, then slowed again. The real cause was a plugin writing fresh autoload data on every page load. Database cleanup did not fix the leak. We had to fix the plugin. Would not make that call again without checking for write patterns first.

There is also a limit to what database optimisation can do. A site with one hundred thousand published posts and a heavy taxonomy structure will be slower than a site with two hundred posts no matter how clean the database is. At some point, the answer is content archival or full re-architecture, not another round of pruning.

And there is one scenario where database maintenance is genuinely not the bottleneck. If you are running enterprise WooCommerce stores with thousands of orders per hour, a complex order metadata structure, and a dedicated team managing the platform, you need enterprise-tier infrastructure with sharding, dedicated database servers, and engineering time on the schema. That workload genuinely suits premium managed WordPress providers built for it. For most Irish business websites, this is overkill, and the operational discipline of a properly managed host on standard managed infrastructure is the right fit.

The only other honest caveat is on Redis. Redis intercepts new transient activity. It does not delete the orphaned transients already sitting in your database from before Redis was switched on. The cleanup of pre-existing bloat still has to happen once, manually, the first time. After that, the Redis layer keeps things from getting worse.

What to do with this

If your site is slower than it used to be, the database is the first place to look, not the last. The signs are quiet by design. Site Health, autoload size, revision counts, and transient sweeps will tell you in about ten minutes whether the database is the problem.

If you are paying a hosting bill every year and nobody has ever mentioned any of this to you, that is worth a separate conversation with your provider. A site that is fast on day one and slow at year three is not a hosting accident. It is a maintenance gap.

Your business deserves a website that is as fast in year four as it was on launch day. The work to keep it that way is not exciting, but it is the work.

Frequently Asked Questions

Why does a WordPress site get slower over time even if I do not change anything?

The database grows in three ways that nobody warns you about. Post revisions accumulate every time you edit a page. The wp_options table fills with autoloaded data from plugins, including plugins you no longer use. Expired transients pile up because WordPress only removes them on next request. Any one of these adds milliseconds to every page load. All three together can add seconds.

How big is too big for the WordPress wp_options autoload?

WordPress recommends keeping autoloaded options under 800 KB. Once you cross 3 MB you should investigate. Anything past 5 MB is a real performance problem. Since WordPress 6.6, there is a Site Health check that flags large autoload sizes for you. Check Tools, Site Health, then look for the autoload warning.

Should I delete post revisions to speed up my WordPress site?

Yes, but carefully. On a site with hundreds of pages and thousands of revisions, pruning revisions to the most recent five per post can shrink the posts table by a meaningful amount. Take a backup first. Use a reputable plugin like WP-Optimize or run the cleanup from WP-CLI. Then add a WP_POST_REVISIONS constant to wp-config.php to cap future growth at five.

What is a transient in WordPress and why does it cause bloat?

A transient is a piece of cached data with an expiry time. Plugins use them to avoid repeating expensive operations. Without a persistent object cache like Redis, transients live in the wp_options table. Expired transients are only removed when something asks for them again. If a plugin sets a transient and then is deactivated or renamed, the data sits there forever.

Does Redis object cache fix WordPress database bloat?

Redis does not delete bloat that already exists in the database. What it does is intercept future transient reads and writes so they hit memory instead of the database. That can reduce wp_options query volume substantially, depending on the site. Combined with regular cleanup of revisions and expired transients, Redis is the difference between a database that grows linearly and one that grows out of control.

Can my hosting provider clean up my WordPress database automatically?

A properly managed WordPress host should be running regular maintenance: pruning expired transients, optimising tables, monitoring autoload size, alerting on growth that looks abnormal. Most cheap shared hosts do not do any of this. They run the server, not the application. If you do not know whether yours does, ask. The answer tells you what kind of provider you actually have.

Sources