Database Cleanup for Slow WordPress Sites: Measure First

Database size is not the same as database speed

Here's the claim that gets pushback every time I say it out loud: your 2GB database can be faster than someone else's 500MB database. Not sometimes. Often.

On the performance audits I've run, I've seen exactly this. A site with a hefty database ran faster than a leaner one because the smaller site had unoptimized queries choking every page load. Database size tells you how much data you're storing. It tells you almost nothing about how fast that data gets retrieved.

This matters because most site owners treat size as a proxy for speed. They see the database has ballooned to a few gigabytes and assume that's why the site crawls. So they spend a weekend deleting revisions, purging transients, and emptying spam folders, feeling productive the whole time. Then they check their load time and it hasn't budged.

The real culprit is usually somewhere else entirely: an N+1 query hammering wp_postmeta, an uncompressed hero image loading at full resolution on every page, or a third-party script blocking render before anything useful shows up. None of those show up when you look at "database size" as a number.

What actually accumulates in your WordPress database and why it matters

WordPress is generous with what it keeps. According to the WordPress Plugin Handbook, the platform stores post revisions, object cache entries, and other data that accumulates over time without any automatic permanent deletion. Nobody flushes it for you.

Spam comments follow the same pattern. Per WordPress's own support documentation, spam stays in the database indefinitely unless you manually delete it or set up a plugin to auto-purge it. Trash posts behave the same way. They sit there, invisible, until someone empties them.

Transients pile up too, and abandoned cron jobs can leave orphaned entries behind. But per the Plugin Handbook's section on transients, transient buildup is rarely in the top three reasons a site feels slow. It's real, it's worth tidying eventually, but it's not usually your bottleneck.

If you're going to clean something, clean what's measurable: spam sitting in the trash, revisions beyond what you actually need (three to five per post is plenty), and metadata orphaned from plugins you uninstalled years ago. Those are concrete. "The database feels big" is not.

Why most sites don't speed up after database cleanup

I've worked with people who spent real time cleaning revisions and transients and saw zero change in page load. The bottleneck the whole time was an oversized image or a plugin firing unthrottled admin-ajax calls in the background. The database was never the problem. It just looked like the obvious problem because it was the thing they could see growing.

Here's a rough gut check: if your query execution time is already fast, somewhere in the neighborhood of 200ms for most requests, clearing out old data in the database is not going to move your load time in any way a visitor would notice. You'd be optimizing something that was never slow.

Database cleanup gets done first because it feels productive. It's visible. You can watch the row count drop. It gives you a sense of control over a problem that otherwise feels vague and technical. Compare that to profiling a slow query or compressing every image on a 200-page site, and it's obvious why cleanup wins the coin flip even when it shouldn't.

If you want a fuller picture of what actually drags a site down before you start touching anything, I wrote up the website speed checklist I run before calling a site done. Database cleanup is on that list. It's just not at the top.

How to diagnose before you clean anything

Before you delete a single row, run a real performance audit. Lighthouse or WebPageTest will tell you whether your slowness is coming from database queries, oversized images, or third-party scripts. This takes minutes and saves you from guessing.

If you suspect the database specifically, check your MySQL slow-query log. That log will show you whether requests are actually slow because of missing indexes on wp_postmeta or wp_posts, rather than because the database is large. Size and speed are just not the same axis.

A rough rule of thumb: if your site loads in under three seconds on a decent connection, database cleanup at this point is maintenance, not optimization. Do it because it's good housekeeping, not because you expect it to fix anything. And if you do it, back up first and know exactly what you're deleting, because automated cleanup tools don't always ask twice before they act.

Sometimes the slowness isn't in WordPress at all, it's a third-party integration or webhook firing constantly in the background and eating server resources on every page load. That's a different diagnosis than a database problem, and if that's what you're chasing, my API & Webhook Integration work covers exactly that kind of debugging.

Safe cleanup: measure, backup, then execute

If your audit points to the database, don't just install a cleanup plugin and click a button. Back up your database first, always. As WordPress's own support docs put it, you want a full backup before running cleanup operations so you can restore if anything goes sideways. This applies whether you're using a plugin, WP-CLI, or phpMuAdmin directly. Try any of this on a staging copy first if you have one, not on the live site.

Manual cleanup through WP-CLI or phpMyAdmin beats a plugin here, and not by a small margin. WP-CLI's database commands let you query and preview exactly what you're about to delete before you commit to it. A plugin usually just runs its logic and reports back afterward. If something in its rules doesn't match your setup, you find out after the data's already gone.

The order matters: measure, audit your actual queries, then decide if cleanup is worth the risk. If the real slowness is elsewhere, the safest move is to skip database cleanup entirely and spend that time on the thing that will actually move the needle.

When database cleanup actually pays off

There are real cases where it helps. If you've genuinely got years of spam sitting in the trash, orphaned metadata from a dozen plugins you removed long ago, or post revisions numbering in the hundreds per post, cleanup will free up disk space and shave time off your backups. That's a legitimate win, just not the same win as "my site is now fast."

Old sites with years of accumulated data benefit from this kind of maintenance on a schedule, the same way you'd clear out an inbox. It's rarely the reason the site is slow, but it keeps things tidy and keeps backups quick to run and restore.

If you're doing it, focus where you'll see actual returns: remove unused transients, purge trash older than thirty days, and prune revisions only if you're seeing dozens or hundreds per post rather than a handful. Anything less than that and you're polishing a doorknob on a house with a cracked foundation.

Before any of this, though, it's worth stepping back and checking whether database cleanup is even the right project. I cover that broader triage in Before You Redesign Your Website, Check These 7 Things First, and if plugin bloat is part of what's slowing you down, this audit guide walks through how to find it.

Will deleting post revisions make my WordPress site faster?

Only if unoptimized queries on wp_posts are actually your bottleneck, and that's rare. Measure first with Lighthouse or WebPageTest. Most slowness traces back to images or third-party code, not revision count.

How many post revisions should I keep?

If you're seeing fifty or more per post across hundreds of posts, cleanup is worth doing. Back up first, and remove old revisions rather than wiping all of them.

Is WP-CLI safer than a cleanup plugin?

Yes. WP-CLI lets you preview changes before running them, so you know what you're deleting before it's gone. Plugins are convenient but can corrupt data if misconfigured. Back up first no matter which method you use.

Should I delete spam comments and trash to speed up my site?

You should delete them, but call it maintenance, not optimization. It saves disk space and backup time. It rarely touches page load speed unless you're dealing with an unusually large volume of spam.

If you've already cleaned your database and your site is still slow, that's not a database problem anymore, that's a diagnosis problem. Get in touch and let's find out what's actually slowing you down before you spend another weekend deleting rows that were never the issue.

FAQ