←back to Blog

WordPress database cleanup guide showing what post revisions and transients to delete safely

WordPress Database Cleanup: What to Delete (and What to Leave Alone)

Every WordPress site I’ve touched in the last 10 years has the same hidden problem: a database dragging around weight it doesn’t need. Nobody notices it happening. You install a plugin, delete it six months later, and the tables it created just sit there. You edit a post forty times and WordPress quietly saves forty full copies. None of it looks like a problem until your site starts feeling sluggish for no obvious reason, and a proper WordPress database cleanup is the fix nobody thinks to try first.

After 950+ Fiverr projects, I’ve opened phpMyAdmin on client sites with a 40MB database that should have been 4MB. Revisions, spam comments, expired transients, orphaned metadata from plugins that were deleted years ago. None of it was doing anything except slowing down every single query. This post covers exactly what to delete, what to leave alone, and how to do it without breaking anything.

Why Your WordPress Database Gets Bloated in the First Place

WordPress was built to never lose your work, so it errs on the side of keeping everything. By default there’s no limit on post revisions. Every autosave and every manual save creates a new row in wp_posts. A page you’ve edited 60 times over two years has 60 old copies sitting in your database right now, forever, unless you tell WordPress otherwise.

Then there are transients: temporary cached data that plugins store in wp_options with an expiration time. The problem is that WordPress doesn’t clean up expired transients on its own. Plugins are supposed to delete their own transients when they expire, but plenty don’t. I’ve seen sites with tens of thousands of expired transient rows because a plugin was uninstalled without ever clearing its own mess.

Add spam comments sitting in moderation, orphaned postmeta left behind after deleted posts, and leftover tables from plugins you removed years ago, and you get a database that’s carrying dead weight on every single page load. This connects directly to why your WordPress site feels slow even on decent hosting: a bloated database means slower queries, and slower queries mean a slower site no matter how good your caching setup is.

What’s Actually Safe to Delete

This is where people get nervous, and honestly, they should be a little nervous. Deleting the wrong thing in your database can take a site down. Here’s what I clean on every maintenance pass, in order of how safe it is:

  • Post revisions — completely safe to trim. Keeping the last 5-10 per post is plenty.
  • Expired transients — safe to remove. They’re temporary by definition; if they’ve expired, nothing needs them.
  • Spam and trashed comments — safe once you’ve confirmed nothing legitimate got caught in there.
  • Orphaned postmeta and commentmeta — safe, but this is where a plugin does it more reliably than a manual SQL query.
  • Unused tables from deleted plugins — safe, but confirm the plugin is actually gone and not just deactivated.

What I don’t touch: wp_options rows I don’t recognize unless I know exactly what plugin created them, anything in wp_usermeta, and I never run a “clean everything” button on a plugin without reviewing the list first. Contrarian opinion here: the plugins that auto-clean weekly without asking are the ones I trust the least. I want to see what’s being deleted before it’s gone.

Capping Post Revisions With wp-config.php

The single most effective fix takes 30 seconds and prevents the problem from coming back. Open wp-config.php and add this above the line that says “That’s all, stop editing”:

define( 'WP_POST_REVISIONS', 5 );
define( 'AUTOSAVE_INTERVAL', 120 );

This caps every post at 5 saved revisions and slows autosave to every 2 minutes instead of every 60 seconds. It won’t clean up revisions you already have, but it stops new bloat from piling up. I add this to every site I build now, it’s on my standard setup checklist alongside the plugins I install by default.

Using WP-Optimize (or Similar) Without Wrecking Anything

For the actual cleanup, I use WP-Optimize. It’s free, it’s been around for years, and it gives you checkboxes instead of forcing you to write SQL. Here’s the process I follow on every client site:

  1. Take a full backup first. Not optional. If you don’t already have this covered, read my backup plugin guide before you touch anything.
  2. Install WP-Optimize and go to the Database tab.
  3. Uncheck anything you’re not sure about. Start with just post revisions, auto-drafts, and trashed items.
  4. Run the cleanup and check your site immediately after. Load the homepage, a post, and the admin dashboard.
  5. Once you trust it, add expired transients and spam comments to future cleanups.
  6. Run the table optimization feature last. This defragments your tables after the deletes, which actually reclaims disk space.

If you’d rather test this somewhere with zero risk before running it on a live site, this is exactly the kind of change that belongs on a staging site first. I’ve seen a “safe” cleanup plugin lock a table mid-optimization on a live WooCommerce store during business hours. Test it once, and you’ll never skip the staging step again.

How Often You Actually Need to Do This

You don’t need a weekly ritual. For most brochure sites and blogs, once a month is plenty. If you’re running WooCommerce, a membership site, or anything with heavy plugin activity, bump that to every two weeks. The WP_POST_REVISIONS constant from earlier does most of the ongoing work for you between cleanups, so this becomes a five-minute task instead of an emergency fix.

The sites I see with the worst database bloat are the ones that installed a cleanup plugin once, ran it, and never opened it again for two years. Set a recurring reminder. It’s a small habit that keeps paying off.

The Bottom Line

A bloated WordPress database won’t crash your site overnight, but it quietly taxes every query, every page load, and every backup you take. Cap your post revisions in wp-config.php today, back up your site, then run one careful cleanup pass with WP-Optimize. It’s a 20-minute job that keeps your site meaningfully faster for months.

Frequently Asked Questions

Yes. Post revisions are just saved copies of past edits, and deleting old ones has no effect on your published content. Keeping the last 5-10 revisions per post is enough of a safety net for almost any site.

Transients are temporary cached data plugins store in your database with an expiration time attached. WordPress doesn’t automatically clean them up when they expire, so expired transients are always safe to delete. Active, non-expired transients should be left alone since something is still using them.

Once a month is enough for most blogs and brochure sites. WooCommerce stores, membership sites, or anything with heavy plugin turnover should aim for every two weeks. Capping post revisions in wp-config.php reduces how much cleanup you need in between.

Yes, though the size of the improvement depends on how bloated your database was. Sites with tens of thousands of expired transients or years of uncapped revisions see the biggest gains, since every query has less dead weight to sift through. It won’t replace caching or good hosting, but it removes one more drag on performance.

Use a plugin like WP-Optimize unless you’re genuinely comfortable reading SQL and know your schema. Manual queries are faster but a single wrong WHERE clause can delete the wrong rows. A plugin with checkboxes and a backup step is the safer call for almost everyone.

Leave a Reply

Your email address will not be published. Required fields are marked *