Clean Your WordPress Database for Better Performance
Post revisions, expired transients, orphaned meta and dead cron events quietly bloat your WordPress database. Here's how to clean each one safely—and schedule it to stay lean.
Nobody sets out to bloat their WordPress database—it just happens. You edit a post twenty times and WordPress silently keeps twenty copies. A plugin you removed a year ago left its scheduled tasks running against nothing. Expired cache entries that were supposed to delete themselves never did. I’ve opened databases on year-old sites and found the useful content was a rounding error next to the junk. Here’s exactly what accumulates, which parts are safe to remove, and how to keep it clean without thinking about it.
The essentials
- The usual bloat: revisions, auto-drafts, trashed/spam comments, expired transients, orphaned meta, duplicate meta, oEmbed cache, and dead cron events.
- The Database Optimizer shows your database size and a count for every cleanable category before you touch anything—and lets you clean each one independently.
- Revisions are kept, not wiped: you set how many to retain (5 by default), so recent editing history survives.
- Cleanup cannot be undone, so back up first—if the Backup module is active, the optimizer reminds you.
- Schedule it daily, twice-daily or weekly and it runs quietly via WordPress cron; comments awaiting moderation are excluded by default so you never lose a real one.
What’s actually clogging your WordPress database?
Most of it is invisible until you go looking. Here’s what a typical site collects, and why each one exists:
- Post revisions — WordPress stores a full copy every time you hit Update. A page edited fifty times carries fifty revisions.
- Auto-drafts — clicking Add New creates a draft row even if you never type a word.
- Trashed posts and comments — deleted content stays in the database until the trash is emptied.
- Spam comments — caught and filed away, but they pile up unless you clear them.
- Expired transients — temporary cached values that were supposed to self-delete and didn’t.
- Orphaned metadata — post, comment, term and user meta whose parent object no longer exists.
- Duplicate metadata — the same meta key stored multiple times in post, comment or user meta.
- Cached oEmbed data — embed previews WordPress caches in postmeta, often long after the embed is gone.
- Dead cron events — scheduled tasks left behind by plugins you’ve since removed, still firing against nothing.
That last pair—duplicate meta and dead cron events—is where most “cleaner” tools stop short, and they’re often the sneakiest contributors on an old site.
Here’s each category at a glance—what it is, and whether it’s safe to clear:
| Data category | What it is | Safe to remove? |
|---|---|---|
| Post revisions | A full copy saved every time you hit Update | Yes—capped, not wiped (keeps 5 by default) |
| Auto-drafts | A draft row created just by clicking Add New | Yes |
| Trashed posts & comments | Deleted content still sitting in the trash | Yes |
| Spam comments | Comments caught and filed as spam | Yes |
| Expired transients | Cached values that were meant to self-delete | Yes |
| Orphaned metadata | Post, comment, term or user meta whose parent is gone | Yes |
| Duplicate metadata | The same meta key stored more than once | Yes |
| Cached oEmbed data | Embed previews cached in postmeta | Yes |
| Dead cron events | Scheduled tasks left by plugins you’ve removed | Yes |
| Comments awaiting moderation | Real comments you haven’t reviewed yet | No—excluded by default |
How do you clean a WordPress database, category by category?
Cleaning a WordPress database safely means clearing each type of clutter independently rather than trusting one “delete everything” button. Activate the Database Optimizer module in Blaminhor Essentials: its overview shows your database size and a live count for every category—revisions, drafts, spam, transients, orphaned and duplicate meta, oEmbed cache and dead cron events—each with its own Clean button, so you see the problem before you act on it.
Every category counted separately, each with its own Clean button—so you decide exactly what goes and what stays.
Each category cleans independently. You’re never forced into a “clean everything” button you don’t trust; clear spam today, leave revisions alone, come back for transients later. Two details matter:
- Revisions are capped, not deleted. You choose how many to keep—five by default—so you clear the backlog without losing your recent editing history.
- Comments awaiting moderation are protected. The optimizer leaves pending comments untouched by default and tells you they weren’t counted, so a legitimate comment you haven’t reviewed yet never disappears in a cleanup.
Does optimizing tables actually reclaim disk space?
Sometimes—and this is where a lot of advice is simply wrong. After deleting rows, MySQL doesn’t always hand the space back. On older MyISAM tables, running OPTIMIZE TABLE genuinely reclaims that freed space, and the optimizer reports it as overhead you can recover.
On modern InnoDB tables—what WordPress uses by default now—it’s different: the “free” space MySQL reports is pre-allocated and managed by the engine, and OPTIMIZE TABLE generally can’t return it to the operating system. So the optimizer deliberately doesn’t count InnoDB free space as overhead, because promising a disk saving it can’t deliver would just be noise. On an InnoDB site, the real win comes from removing the junk rows themselves—lighter tables and faster queries—not from chasing a megabyte counter. It’s a small thing, but it’s the difference between an honest tool and one that inflates its own numbers.
Can you set it and forget it?
Yes—and that’s the point. Turn on scheduled cleanup and pick a cadence: daily, twice-daily or weekly (weekly is the default). From then on it runs in the background via WordPress cron, clearing the categories you enabled without you lifting a finger. The Database Optimizer even surfaces a summary on your dashboard when cruft builds up, with a one-click cleanup right there.
How often is often enough?
For most sites, weekly or monthly keeps things tidy without any downside. If you run a busy multi-author blog or a WooCommerce store generating orders and revisions all day, lean toward the more frequent end. The goal isn’t to obsess over a lean database—it’s to stop bloat from ever building up in the first place. Set the schedule once and let it work.
A clean database pairs naturally with the other performance basics: once the tables are lean, caching and front-end optimization give you the visible speed win visitors actually feel.
Database Optimizer is one of the 20+ tools in Blaminhor Essentials—free and open-source on WordPress.org.
– blaminhor
FAQ
Does cleaning the WordPress database actually make it faster?
It can, in two ways: smaller tables mean lighter queries, and removing thousands of stale rows (especially in wp_postmeta and wp_options) reduces the work WordPress does on every page load. The gain is biggest on old, never-cleaned sites; on a well-maintained one it's more about keeping bloat from creeping back.
Is it safe to clean my WordPress database?
Yes, if you back up first and understand each category. Standard items like revisions, spam and expired transients are safe to remove. The one to leave alone is comments awaiting moderation, which the Database Optimizer excludes by default. Always create a backup before a cleanup, since the operation cannot be undone.
Can I clean my WordPress database without a plugin (phpMyAdmin/SQL)?
You can, using phpMyAdmin and SQL — for instance deleting rows where post_type is « revision ». But raw queries are unforgiving: one wrong WHERE clause and you lose real content, with no confirmation and no undo. Back up first, and honestly a tool that previews the counts is far safer for most people.
How do I limit or reduce post revisions in WordPress?
Add « define('WP_POST_REVISIONS', 5); » to wp-config.php to cap how many copies WordPress keeps per post, or set it to false to switch revisions off entirely. That stops new ones piling up; to clear those already stored you still need a cleanup. The Database Optimizer caps revisions rather than wiping your recent history.
Why is my WordPress database so large?
Often it's the wp_options table. Plugins store settings there with « autoload » set to yes, so WordPress loads every one on every single page — sometimes megabytes you never use. Expired transients and orphaned metadata pile on top. Trimming autoloaded junk and stale rows is where the real weight comes off.
Will cleaning my database delete any of my posts or content?
No. A proper cleanup targets clutter — revisions, spam, expired transients, orphaned rows — never your published posts, pages or approved comments. The Database Optimizer even leaves comments awaiting moderation untouched by default. The only real safeguard, though, is a backup before you run it, because the operation can't be undone.
Comments