The WordPress sites we maintain longest tend to slow down in a predictable pattern. The front end gets plenty of attention — caching, image optimization, lazy loading — but the database quietly fills up with leftovers from plugins that haven't been active in years, expired transients nobody cleaned up, and autoloaded options that were never meant to be autoloaded. When a site starts feeling heavy and the obvious suspects check out, the database is the first place our team looks.
Why the Database Usually Gets Ignored
Most performance advice focuses on what you can see: PageSpeed scores, image sizes, render-blocking scripts. Those things matter. But WordPress pulls a chunk of data from the database on every single request, before any page code even runs, and when that chunk grows bloated, no amount of front-end tuning will rescue you. A site with clean templates and a 15 MB autoload payload will always feel slower than one with messy code and a lean database. The database is the floor — everything else sits on top of it.
Three or four years of plugin churn, abandoned settings, expired caches, and runaway post revisions add up quietly. Nobody notices until response times creep past two seconds and page loads start feeling sluggish for no apparent reason.
The wp_options Table and Autoloaded Data
The wp_options table stores site-wide settings — everything from the site URL to plugin configurations to cached API responses. Each row has a flag called autoload. When it's set to yes, WordPress loads that row on every request, whether the current page needs it or not.
A healthy site carries somewhere between 200 KB and 500 KB of autoloaded data. Above 1 MB is worth investigating. Above 3 MB and you'll feel it. We've inherited sites with 15 MB of autoloaded options where every page load was burning 200-plus milliseconds just loading that data into memory before doing anything useful.
How to check your autoload size
Open phpMyAdmin (or whichever database tool your host provides) and run this query:
SELECT ROUND(SUM(LENGTH(option_value))/1024/1024, 2) AS "Autoload MB" FROM wp_options WHERE autoload='yes';
One number comes back. Under 1 MB is fine. Over 3 MB and something needs cleaning. To find the worst offenders, this second query lists the ten largest autoloaded rows by size:
SELECT option_name, LENGTH(option_value) AS bytes FROM wp_options WHERE autoload='yes' ORDER BY bytes DESC LIMIT 10;
What WordPress 6.6 changed
Starting with WordPress 6.6, core began auto-disabling autoload on options that exceed a size threshold, which prevents the worst runaway cases going forward. That's a backstop, not a cleanup. It doesn't touch the bloat already in the database — it just stops new bloat from being added to every page load. Anything that was already autoloading before the upgrade keeps right on autoloading.
Transients: Useful, Until They Aren't
Transients are pieces of cached data with an expiration time, typically used by plugins to avoid repeating an expensive operation — an external API call, a slow query, a widget that pulls in social feeds. In theory, expired transients get cleaned up automatically. In practice, they often don't, especially on sites without an external object cache. Expired transients sit in wp_options indefinitely.
When we audit a client site with bloated autoload, stale transients are usually the biggest single category. Plugins that hit external APIs — SEO tools, social feed widgets, currency converters, analytics aggregators — are the worst offenders.
Orphaned Plugin Data
Deactivating a plugin doesn't delete its data. Deleting a plugin often doesn't either, because developers worry about removing something a site owner might still want. The result is a database slowly filling with settings for plugins that haven't existed on the site in years.
Redirect plugins and page-builder plugins tend to leave the most behind. We've seen a single abandoned redirect plugin contribute four megabytes of autoloaded data, years after it had been uninstalled. Nobody knew it was there.
Post Revisions, Spam, and Trash
These don't live in wp_options — they sit in wp_posts and wp_comments — but they matter for different reasons. They don't slow every page load, but they bloat backups, slow down queries that scan the posts table, and make migrations take far longer than they should. A ten-year-old blog with unlimited revisions enabled can easily carry 50,000 extra rows in wp_posts that nobody will ever read.
WordPress now limits revisions by default, but older sites accumulated them freely and nothing ever came back to clean them up. Spam comments and trashed posts have the same story.
How We Approach a Cleanup
The routine we run for clients looks roughly like this:
- Back up first. A full database export before touching anything. Non-negotiable.
- Measure autoload size with the query above, so there's a before number to compare against.
- Identify the biggest autoloaded rows. Usually five or six rows account for most of the bulk.
- Trace each row to a plugin. If the plugin is active and needs the data, disable autoload but keep the row. If the plugin is gone, delete the row.
- Clear expired transients with a targeted SQL query, not a generic cleanup plugin.
- Trim post revisions to a reasonable limit (usually 5 to 10) and remove the older ones.
- Empty spam comments and trashed posts that have been sitting there for months.
- Run OPTIMIZE TABLE on the major tables afterward to reclaim physical disk space.
- Retest. Measure response time before and after. Clients want to see the difference, and so do we.
Most clients see a noticeable TTFB improvement after this — commonly 100 to 300 milliseconds off the first byte, which compounds across every page view. The work takes two or three hours on an average site. On a badly bloated one, it can take a day.
A Word of Caution
Database cleanup is one of those areas where a confident Saturday afternoon with a cleanup plugin can take a site down. The plugins that promise one-click optimization don't know which options your theme reads on init. They don't know which plugin stores critical license keys under an innocuous-looking option name. They'll happily delete the wrong thing, and the error message afterwards is almost never helpful.
If you run a WordPress site that matters to your business and you suspect the database is the bottleneck, don't guess. Our WordPress maintenance plans include quarterly database health checks and cleanup as part of the standard service. A clean database costs less than a broken one, and a broken one costs a lot more than either.
If your site is already feeling slow and you want someone to look at it properly, that's a conversation worth having. We'll run the diagnostics on a staging copy, tell you exactly what we find, and you'll know whether the fix is an hour of work or a week of it before we touch anything live.