WordPress Database Bloat: Clean It Up Without Breaking Anything

WordPress database bloat — accumulated post revisions, expired transients, and oversized autoloaded options — is one of the most common, least-visible reasons a site gets sluggish over time. The good news: most of it can be cleaned up safely in under an hour, and the performance difference is often immediate and measurable. The important word is safely — a rushed cleanup without a backup can delete data you actually need.

This guide covers all three culprits in detail: what they are, how to measure the damage, how to clean them up in the right order, and how to keep them from coming back.

Why Your Database Slows Down Silently

WordPress stores almost everything in MySQL — posts, settings, plugin data, caches, session tokens, widget configurations. Over months and years, several categories of data accumulate without any automatic pruning:

• Post revisions. Every time you save a draft or update a published post, WordPress stores a full copy of that post. A heavily-edited page can generate 50 or more revisions, and none of them are ever deleted by default.
• Expired transients. Transients are a WordPress caching mechanism — plugins store temporary data with an expiry time. On sites without object caching, expired transients accumulate in wp_options rather than being cleaned up promptly.
• Autoloaded options. Rows in wp_options marked autoload = yes are loaded into memory on every single page request. Many plugins add rows here and never clean them up on uninstall. When the total autoloaded payload climbs past a few megabytes, every page load slows down.

None of this causes an error message. The site just gets heavier. Query times creep up. Time-to-first-byte increases. If you're investigating a slow site, measuring database bloat is one of the first things to do — before buying more hosting or fiddling with caching configuration.

Step 0: Back Up First — Every Time

Database cleanup means running DELETE queries. There is no undo button. Before touching anything, take a full database backup. Your host's control panel, a plugin like UpdraftPlus, or a WP-CLI command (wp db export backup.sql) all work fine. Store the backup somewhere off-server. This is non-negotiable.

Step 1: Measure the Actual Bloat

Before cleaning, understand what you have. Log in to phpMyAdmin (available in most hosts' control panels), select your WordPress database, and run this query:

SELECT table_name, ROUND((data_length + index_length) / 1024 / 1024, 2) AS size_mb
FROM information_schema.tables
WHERE table_schema = DATABASE()
ORDER BY size_mb DESC;

This shows which tables are largest. A wp_posts table over 50 MB on a modest blog almost always contains revision bloat. A wp_options table over 10 MB is a red flag for autoload and transient problems.

For autoloaded data specifically, run:

SELECT SUM(LENGTH(option_value)) / 1024 / 1024 AS autoload_mb
FROM wp_options
WHERE autoload = 'yes';

Anything over 1–2 MB warrants investigation. Values over 5 MB are actively harming performance on most shared hosts.

Step 2: Clean Up Post Revisions

Revisions live in wp_posts with post_type = 'revision'. You have two safe approaches:

Option A: WP-CLI (recommended)

wp post delete $(wp post list --post_type='revision' --format=ids) --force

This deletes all revisions in one command and is the cleanest method. Run it from your server via SSH.

Option B: Direct SQL in phpMyAdmin

DELETE FROM wp_posts WHERE post_type = 'revision';

Safe on its own, but also clean up orphaned postmeta for those revisions:

DELETE pm FROM wp_postmeta pm
LEFT JOIN wp_posts p ON pm.post_id = p.ID
WHERE p.ID IS NULL;

Limit future revisions

After cleaning, add this to your wp-config.php to cap revisions going forward:

define( 'WP_POST_REVISIONS', 5 );

Five is a sensible default — enough for recovery, not enough to bloat the table. You can set it to false to disable revisions entirely, but most editors benefit from having a few.

Step 3: Delete Expired Transients

Expired transients have a corresponding row in wp_options with an option name like _transient_timeout_xyz where the stored value is a Unix timestamp in the past. The cleanest way to remove them:

DELETE FROM wp_options
WHERE option_name LIKE '_transient_%'
AND option_name LIKE '%timeout%'
AND option_value < UNIX_TIMESTAMP();

Then clean up the orphaned transient values themselves:

DELETE FROM wp_options
WHERE option_name LIKE '_transient_%'
AND option_name NOT LIKE '_transient_timeout_%'
AND CONCAT('_transient_timeout_', SUBSTRING(option_name, 13))
    NOT IN (SELECT option_name FROM wp_options);

Alternatively, WP-CLI handles this in one step:

wp transient delete --expired

And to delete all transients (safe if you have a persistent object cache, since they'll be regenerated):

wp transient delete --all

Important: If your site uses a persistent object cache like Redis or Memcached, transients are stored there rather than in the database and this cleanup has minimal impact — which is one more reason a persistent object cache is worth installing on any active site.

Step 4: Audit and Shrink Autoloaded Options

This step requires more judgment than the others. Autoloaded options are legitimate — WordPress core and every plugin use them. The problem is abandoned plugin data from plugins you've since removed, and poorly-behaved plugins that store large blobs with autoload = yes.

Start by listing the top offenders:

SELECT option_name,
       LENGTH(option_value) AS value_bytes,
       autoload
FROM wp_options
WHERE autoload = 'yes'
ORDER BY value_bytes DESC
LIMIT 30;

Look for option names that reference plugins you don't use, or suspiciously large values (anything over 100 KB in a single autoloaded row is worth questioning). You can safely change the autoload flag for rows you identify as non-critical:

UPDATE wp_options
SET autoload = 'no'
WHERE option_name = 'some_plugin_option_name';

Do not delete rows you don't recognise. Deleting a core option by mistake can break your site. Change the autoload flag first, test thoroughly, and only then consider deletion if the plugin is fully removed.

For rows from plugins you've already deleted, it's safe to remove the entire row:

DELETE FROM wp_options WHERE option_name = 'deleted_plugin_option';

Step 5: Optimise the Tables

After deleting a large number of rows, MySQL tables can have fragmented free space. Run OPTIMIZE TABLE to reclaim it:

OPTIMIZE TABLE wp_posts, wp_options, wp_postmeta;

Or via WP-CLI:

wp db optimize

On large tables this can take a few minutes. On shared hosting it's fine to run during low-traffic hours.

Preventing Bloat From Coming Back

• Set WP_POST_REVISIONS in wp-config.php to 3–5 and leave it there.
• Install a persistent object cache. Redis or Memcached keeps transients out of the database entirely. Many managed hosts include this; ask yours.
• Audit plugins before installing them. Check the plugin's uninstall routine — a well-maintained plugin cleans up its own data. Plugins that don't are a known source of long-term bloat.
• Run a scheduled database cleanup quarterly. WP-CLI makes this scriptable. A cron job running wp transient delete --expired monthly costs nothing and keeps the table clean.
• Use a maintenance routine. Regular audits catch bloat before it becomes a performance problem. Our post on the WordPress maintenance routine that actually prevents emergencies covers the full schedule.

When to Call a Professional

Most database cleanups are safe to run yourself if you follow the steps above in order and you have a fresh backup in hand. Call in a professional if:

• Your autoloaded options table is over 10 MB and you're not sure which rows are safe to touch.
• The site is running slow but the cleanup didn't help — the problem may be slow queries, missing indexes, or under-resourced hosting.
• You want the cleanup paired with a full performance audit, including caching configuration and image optimisation.
• You ran a cleanup and something broke — stop, restore your backup, and get a second pair of eyes before trying again.

If any of those sound familiar, Mend's Speed Pass is a flat-rate performance fix that includes a database audit, cleanup, caching configuration, and a plain-English report of exactly what changed — same-day on most sites. Or if you're not sure what's causing the slowdown, a free Diagnosis will triage the problem and quote a flat price before any work begins.

Database bloat is a slow, invisible tax on every page load. The cleanup is methodical and safe when done in the right order — measure first, back up, clean revisions, clear transients, audit autoloads, optimise tables, then put controls in place so it doesn't accumulate again. Most site owners who do this once and set the revision limit see a noticeable speed improvement without touching a single line of theme code or changing their hosting plan.

For a broader look at what's slowing your site down beyond the database, see our full guide: Speed Up WordPress: Why Your Site Is Slow and How to Fix It.