Clean Up WordPress Database Bloat: Revisions, Transients & Options

WordPress database bloat occurs when tables become overloaded with unnecessary data, such as thousands of post revisions, expired transients, and oversized autoloaded options. Cleaning this leftover data reduces database size, speeds up query execution times, and significantly improves server response times (TTFB) and admin dashboard speed. Always perform a full database backup before removing rows or running SQL queries directly on your site.

What Is WordPress Database Bloat and Why Does It Slow Down Your Site?

Every time you publish a post, save a draft, install a plugin, or update a theme, your database records new information. By default, WordPress rarely deletes old data automatically. Over months or years, a database that should weigh 20 to 50 megabytes can easily balloon into hundreds of megabytes or even gigabytes.

When your database gets bloated, your web server has to work significantly harder on every single page request. Instead of pulling data cleanly from memory, MySQL or MariaDB must scan thousands of unnecessary rows across several core tables. This overhead directly impairs site performance, often causing distinct symptoms across your site:

• Sluggish WordPress Admin Area: Saving posts, switching tabs in the dashboard, or loading plugin settings takes 3 to 10 seconds.
• High Time to First Byte (TTFB): Visitors experience a noticeable delay before the page starts rendering because database queries take too long to resolve.
• Database Server Timeouts: You encounter database connection drops or "MySQL server has gone away" errors during peak traffic spikes or scheduled tasks.
• Ballooning Hosting Resource Usage: Your hosting provider warns you about excessive CPU, RAM, or database size limit exceedances.

To eliminate database bloat effectively, you need to target the three primary culprits responsible for over 90% of database bloat in WordPress: post revisions, expired transients, and oversized autoloaded options.

Step 0: Always Create a Complete Database Backup First

Cleaning a database involves deleting data permanently from tables like wp_posts and wp_options. If an SQL query goes wrong or a plugin deletes serialized option data improperly, your site can instantly break or show critical errors. Before running any commands or executing database optimization tools, create a fresh, verified database backup using your hosting control panel (such as cPanel, MyKinsta, or SpinupWP) or a backup plugin.

Culprit 1: Post Revisions and Old Drafts

By default, WordPress saves a new revision every time you update a post or page. While revisions are helpful for restoring earlier content drafts, a site with hundreds of posts published over several years can easily store 10,000+ revision entries in the wp_posts table. Each revision also creates corresponding meta entries in wp_postmeta, multiplying the bloat.

How to Purge Revisions Safely

You can remove existing post revisions using WP-CLI or a dedicated database optimization plugin like WP-Optimize or Advanced Database Cleaner. If you have terminal access, the safest and fastest way is via WP-CLI:

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

If you prefer running a direct SQL query in phpMyAdmin, execute the following query to remove all post revisions and their associated meta data:

DELETE a,b,c
FROM wp_posts a
LEFT JOIN wp_term_relationships b ON (a.ID = b.object_id)
LEFT JOIN wp_postmeta c ON (a.ID = c.post_id)
WHERE a.post_type = 'revision';

Note: If your database table prefix is not wp_, replace wp_posts, wp_term_relationships, and wp_postmeta with your actual table prefix (e.g., wp_5x_posts).

How to Prevent Future Revision Bloat

You can limit the maximum number of revisions WordPress stores per post by adding a single line to your wp_config.php file. Open wp-config.php and add this directive above the line that reads /* That's all, stop editing! Happy publishing. */:

define('WP_POST_REVISIONS', 5);

Setting this value to 5 ensures WordPress keeps only the five most recent revisions per post, discarding older ones automatically.

Culprit 2: Expired Transients in wp_options

Transients are a simple form of caching inside WordPress that store temporary data (such as API responses, expiration timers, or external RSS feeds) inside the wp_options table. When transients expire, WordPress is supposed to clear them when a page requests them. However, if a plugin creates hundreds of unique temporary transients that are never requested again, they remain in the database indefinitely as garbage rows.

How to Purge Expired Transients

If you have WP-CLI installed, you can purge all expired transients across the site with one command:

wp transient delete --expired

To purge all transients (both active and expired, forcing plugins to regenerate fresh data):

wp transient delete --all

If you prefer using phpMyAdmin, run this SQL query to safely target and delete expired transient records from the wp_options table:

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

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

Culprit 3: Oversized Autoloaded Options

This is frequently the single largest cause of slow database response times on WordPress sites. Autoloaded options are settings stored in the wp_options table where the autoload column is set to yes (or on in newer WordPress versions). On every single page load, WordPress executes a single database query that pulls all autoloaded options into PHP memory.

Ideally, total autoloaded data should remain under 800 KB (and under 500 KB on high-performance sites). If plugins store huge arrays, page builder caches, or tracking logs inside autoloaded options, this payload can skyrocket to 5 MB, 10 MB, or more, slowing down every single page request across your entire site.

1. Check Your Total Autoloaded Size

Run this query in phpMyAdmin to determine the exact memory footprint of your autoloaded options:

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

If the result is greater than 1 MB, your site will benefit significantly from reducing this footprint.

2. Identify the Largest Autoloaded Rows

To find out which specific plugins or options are taking up the most space, run this query:

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

3. Turn Off Autoload for Non-Essential Options

Once you identify massive options that do not need to load on every frontend page request (for instance, uninstalled plugin remnants or backend administrative logs), change their autoload state from yes to no:

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

Warning: Never delete or turn off autoload for critical core options such as siteurl, home, active_plugins, or template. Doing so will make your site unrenderable or trigger a WordPress White Screen of Death.

How to Keep Your WordPress Database Clean Long-Term

1. Limit Revisions and Autosaves in wp-config.php: Keep revisions limited to 5 and extend the autosave interval from 60 seconds to 300 seconds using define('AUTOSAVE_INTERVAL', 300);.
2. Clean Up Uninstalled Plugin Tables: Many plugins leave custom tables behind when uninstalled. Delete orphan tables manually or using WP-CLI after deinstalling old plugins.
3. Optimize Table Storage: Periodically run an SQL OPTIMIZE TABLE command on key tables (wp_posts, wp_postmeta, wp_options) to defragment storage after deleting large amounts of data.
4. Schedule Automated Database Cleanup: Use a lightweight maintenance plugin or cron job to prune trash comments, expired transients, and draft revisions on a monthly basis.

When to Call a Professional Engineer

Database optimization is straightforward when dealing with post revisions, but modifying the wp_options table or altering serialized data directly in SQL carries serious risk. Misconfiguring autoloaded options or deleting referenced IDs across wp_postmeta can break plugin settings, disconnect WooCommerce product variations, or lead to an Error Establishing a Database Connection.

If your WordPress admin remains extremely slow despite basic cleanup, if your database has corrupted tables, or if you aren't comfortable executing raw SQL commands, it is safer to let an experienced engineer handle it.

Through Mend's Speed Pass, senior WordPress engineers inspect your database, identify bloated autoloaded options safely without breaking serialized arrays, prune orphan data, and optimize server response times. If your database error is actively crashing your site, you can submit a Emergency Rescue request or get a free diagnosis before any work begins.

Related guides from our blog: Learn how to speed up WordPress comprehensively or troubleshoot frontend rendering with our guide on how to eliminate render-blocking resources without breaking your site.