A WordPress database rarely gets cleaned, because nothing visibly breaks as it grows. The site just gets a little slower — admin screens take an extra beat, saving a post drags, backups balloon — until one day wp-admin feels like wading through mud and nobody can point to a single cause. This guide is about finding the bloat that actually matters, removing it safely, and keeping it from coming back. I’ll start with the one table that affects every single page load, because that’s where most of the real damage hides.
The Autoload Problem: Why wp_options Runs Your Whole Site
Every time WordPress loads a page — front end or admin — one of its first jobs is a single database query that pulls every row from the wp_options table where autoload is set to yes, and holds them all in memory for the rest of the request. Settings, plugin configuration, widget data, site options: if it’s autoloaded, it’s loaded on every page view, whether that page needs it or not.
When a site is new, that autoloaded data is small — a few hundred kilobytes — and the query is effectively free. The problem is accumulation. Plugins store their settings as autoloaded options by default, and plenty of them never clean up: deactivate and delete a plugin three years ago, and its options are often still sitting in your database, loading on every request. Add themes you test-drove, page builders, analytics tools, and transients parked in the options table (more on those below), and autoloaded data can quietly grow into the megabytes.
As a working rule from audits: under roughly 500 KB of autoloaded data is healthy, around 1 MB deserves a look, and several MB will measurably slow both the front end and wp-admin — especially on shared hosting, where database memory and CPU are tight. If your admin is chronically sluggish, this is one of the first places I check; I cover the other usual suspects in my guide to fixing a very slow WordPress admin.
The Other Usual Sources of Bloat
Autoload is the headline act, but it’s not the whole database:
- Post revisions. Every time you save a draft, WordPress stores a full copy of the post. Edit a long article thirty times and you’ve stored thirty near-complete versions of it. On an old, actively edited site, revisions can outnumber actual posts several times over.
- Auto-drafts and trashed content. Drafts WordPress saved automatically, plus posts, pages, and comments sitting in the trash, all occupy real rows until they’re permanently deleted.
- Spam and pending comments. A site that’s been online for years can hold thousands of spam comments that were never purged.
- Expired transients. Transients are temporary cached values with an expiry time. When a site has no persistent object cache, they’re stored in
wp_options— and expired ones don’t always get deleted. They pile up, and because many are autoloaded, they feed the problem above. - Orphaned metadata. Rows in
wp_postmeta,wp_commentmeta, andwp_term_relationshipsthat point to posts, comments, or terms that no longer exist. Harmless individually, dead weight in bulk. - Leftover tables. Uninstalled plugins frequently leave entire tables behind. These don’t slow page loads (WordPress never queries them), but they bloat backups and migrations.
Rule Zero: Back Up Before You Touch Anything
Database cleanup is deleting data. Most of it is safe, some of it is one misclick away from a bad afternoon, and none of it is undoable without a backup. Before any cleanup session:
- Take a full backup — files and database — with your host’s backup tool or a plugin like UpdraftPlus, and make sure it completes.
- Download a separate database-only export from phpMyAdmin (Export → Go) so you have a copy that doesn’t depend on any plugin to restore.
- Note the time. If anything looks wrong later, you want to know exactly which backup predates the cleanup.
If you maintain a staging copy of your site, run the cleanup there first. If you don’t, the backup discipline above is your safety net — don’t skip it because the plugin “looks trustworthy.”
Step 1: See What You’re Dealing With (phpMyAdmin)
Log into phpMyAdmin (via your hosting panel), select your WordPress database, and open the SQL tab. Two queries give you the full picture in under a minute. If your tables use a custom prefix, replace wp_ with yours.
Total autoloaded size:
SELECT SUM(LENGTH(option_value)) AS autoload_bytes
FROM wp_options
WHERE autoload = 'yes';(Newer WordPress versions also use values like auto for some options; if the result looks suspiciously small, run it with WHERE autoload IN ('yes', 'on', 'auto').)
The biggest autoloaded options, so you know who’s responsible:
SELECT option_name, LENGTH(option_value) AS bytes
FROM wp_options
WHERE autoload = 'yes'
ORDER BY bytes DESC
LIMIT 20;The names usually give the owner away — they’ll typically start with the plugin or theme’s name. What you’re looking for: options belonging to plugins you no longer use (safe to remove once confirmed, see below), and single options that are absurdly large, like old plugin data storing logs or cached feeds as one giant serialized row.
While you’re in phpMyAdmin, glance at the table list sorted by size. wp_posts dominated by revisions, a wp_options table far bigger than expected, or an unknown table with tens of thousands of rows all tell you where to aim the cleanup.
Step 2: Clean Up with a Plugin (the Sensible Default)
For most site owners, a reputable cleanup plugin is the right tool — it knows which rows are safe to delete and presents counts before you commit. Three solid options:
WP-Optimize — the database tab lists each cleanup type with a count: revisions, auto-drafts, trashed posts, spam comments, expired transients, and orphaned metadata. Run them individually rather than hitting “optimize everything,” and eyeball the numbers first. If it claims you have 40,000 revisions, that’s real information about how the site has been edited.
LiteSpeed Cache — if you already use it for page caching, its Database Optimizer section (under LiteSpeed Cache → Database) covers the same core cleanups, so there’s no need to install a second plugin just for this.
Perfmatters — its database optimization runs on a schedule (weekly or monthly), which makes it the best fit for the maintenance routine at the end of this guide. It also lets you limit stored revisions and control the autosave interval — prevention, not just cleanup. (I’ve compared its script-management side against Asset CleanUp here, but the database tools are a genuine bonus.)
Cautions that apply to every tool
- “Orphaned” detection isn’t perfect. A row a plugin flags as orphaned is occasionally live data whose parent reference it doesn’t understand. This is what the backup is for — and why you run one category at a time and check the site afterward.
- Don’t delete options or tables belonging to active plugins. If a plugin is installed and in use, its data stays, however large. The targets are plugins and themes that are gone.
- WooCommerce data regenerates and matters. Transients, sessions, and webhook/log tables in WooCommerce churn constantly. Clearing expired transients is safe; bulk-deleting anything order- or customer-related is not cleanup, it’s data loss.
- Expect transients and some tables to come back. Plugins recreate what they need. Cleanup is maintenance, not a one-time exorcism.
After cleaning, visit the site logged out, load a few key pages, log into wp-admin, and confirm everything behaves. Only then delete the pre-cleanup backup… actually, don’t — keep it for a few weeks. Storage is cheap; regret is expensive.
Step 3: Stop the Bloat Coming Back
Cleanup without prevention is a subscription to doing this again in six months. Three settings in wp-config.php (above the “That’s all, stop editing!” line) cap the biggest regrowth source:
define('WP_POST_REVISIONS', 5); // keep the last 5 revisions per post
define('AUTOSAVE_INTERVAL', 300); // autosave every 5 minutes, not 60 seconds
define('EMPTY_TRASH_DAYS', 14); // purge trash after 14 days instead of 30And one habit: when you test a plugin, decide quickly. Plugins that live on your site for a weekend and get deleted are the single biggest source of orphaned options and leftover tables. Once or twice a year, scan the options table for names belonging to products you no longer run, and remove those rows (backup first, always).
A persistent object cache helps here too in an indirect way: with Redis set up, transients move out of wp_options into memory storage, which stops one of the steadiest autoload growth sources entirely.
A Simple Monthly Maintenance Routine
Ten minutes a month keeps a database from ever reaching the problem stage:
- Check autoload size — run the first SQL query above, or your cleanup plugin’s report. Note the number; a sudden jump means a plugin is misbehaving.
- Run the safe cleanups — revisions beyond your cap, auto-drafts, trashed posts and comments, spam comments, expired transients. (Perfmatters or WP-Optimize can do this on a schedule; scheduling it beats remembering it.)
- Empty the trash in posts, pages, and comments if
EMPTY_TRASH_DAYShasn’t already. - Glance at table sizes in phpMyAdmin for anything that’s grown oddly since last month.
- Confirm your backups are running — the routine is only safe because they are.
When Cleanup Won’t Fix It
Be honest about the limits: if your autoload is already small and your tables are tidy, the database is not your bottleneck, and scrubbing it won’t move your load times. A large database mostly hurts wp-admin, post saving, and uncached/dynamic pages; a properly page-cached front end can feel fast with a messy database behind it. If pages are slow for visitors, the cause is more likely hosting power, unoptimized images, or render-blocking assets — work through this diagnostic guide to find the real culprit before optimizing the wrong layer.
For most sites that have been live a few years, though, the first cleanup is genuinely satisfying: a megabyte or two out of the autoload, an admin that responds when you click, and backups that finish in half the time. Ten minutes a month keeps it that way.