WordPress Revisions and Autosave: The Hidden Database Bloat Slowing Your Site

Every time you click “Update” on a WordPress post, WordPress saves a complete copy of the previous version. This is the revisions system — a built-in safety net that lets you roll back to an earlier draft if something goes wrong. It’s a genuinely useful feature. It’s also one of the most common sources of database bloat on long-running WordPress sites.

On a site that’s been active for a few years, the wp_posts table can contain many more revision records than actual published content. Those rows don’t just sit quietly — they participate in database queries, inflate backup sizes, and slow down operations that touch the wp_posts table.

How WordPress Revisions Work

Every time you save or update a post, WordPress stores the previous version as a new row in wp_posts with post_type = 'revision' and a post_status = 'inherit'. The revision row is linked to the parent post via post_parent.

Autosaves are a related but distinct mechanism. While you’re actively writing in the editor, WordPress sends an autosave to the server every 60 seconds. This creates a row with post_status = 'auto-draft' or updates an existing autosave revision. Autosaves exist to protect against browser crashes — they’re separate from the revision history you see in the editor’s “Revisions” panel.

The result: for every published post, you may have dozens of associated rows in wp_posts. A site with 500 posts updated regularly over three years can easily have 5,000 to 15,000 revision rows — or more.

The Performance Impact

The most direct impact is on database query time for any operation that queries wp_posts without filtering by post_type. Some plugins, custom code, and older WordPress functions can inadvertently pull revision rows into results, requiring extra filtering to exclude them.

More broadly, the sheer size of wp_posts affects:

• Backup size and duration — your backup plugin exports every row, including revisions
• Database index size — larger tables mean larger indexes, which take longer to scan
• Admin performance — the Posts list screen runs COUNT queries that include revision rows in some contexts
• Object cache pressure — if you’re using Redis or Memcached, revision metadata can compete for cache slots alongside actual content

None of these individually will take down your site, but together they represent sustained overhead that compounds over time.

Checking How Many Revisions You Have

Before making changes, it helps to know the scope of the problem. You can check from wp-admin under Tools > Site Health > Info, or run this query from phpMyAdmin or your host’s database tool:

SELECT COUNT(*) FROM wp_posts WHERE post_type = 'revision';

You can also use WP-CLI if your host supports it:

wp post list --post_type=revision --format=count

A count in the thousands is common on active sites. A count in the tens of thousands suggests the revisions system has been running unchecked for a long time.

Limiting Revisions Going Forward

The most sustainable fix is to cap how many revisions WordPress keeps per post. Add this to your wp-config.php file:

define( 'WP_POST_REVISIONS', 5 );

This tells WordPress to keep a maximum of five revisions per post. When a sixth is saved, the oldest is deleted automatically. You can set this to any number that makes sense for your workflow — most site owners find three to five revisions is more than enough for practical rollback purposes.

To disable revisions entirely:

define( 'WP_POST_REVISIONS', false );

This is a reasonable choice for sites where content is rarely edited after publishing — news sites, product catalogs, and similar use cases. Be aware you lose the rollback safety net entirely, so it’s worth considering whether you actually use revisions before disabling them.

You can also set this per post type using a filter, if you want revisions for pages but not posts:

add_filter( 'wp_revisions_to_keep', function( $num, $post ) {
    if ( $post->post_type === 'post' ) {
        return 3;
    }
    return $num;
}, 10, 2 );

Controlling the Autosave Interval

The autosave interval defaults to 60 seconds. For most editors this is fine, but if you find autosaves creating noise in your revision history or contributing to database writes you’d rather avoid, you can increase the interval:

define( 'AUTOSAVE_INTERVAL', 300 ); // autosave every 5 minutes

This is a tradeoff: a longer interval means more potential work lost if something goes wrong during writing. Don’t set this excessively high if writers depend on it as a safety net.

Cleaning Up Existing Revisions

Setting WP_POST_REVISIONS going forward doesn’t remove revisions that already exist. To clean those up, you have a few options.

WP-CLI (fastest and most reliable)

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

This deletes all existing revision rows permanently. The --force flag bypasses the trash (revisions don’t go to trash anyway, but the flag prevents any prompts). Run this in a maintenance window or at low-traffic time, as it generates database write activity proportional to the number of revisions.

If you have a large number of revisions, batch the operation to avoid timeouts:

wp post list --post_type=revision --format=ids | xargs -n 100 wp post delete --force

Using a Plugin

If you don’t have WP-CLI access, plugins like WP-Sweep or Advanced Database Cleaner can delete revisions from wp-admin. These are one-time cleanup tools — install, run the cleanup, then uninstall. There’s no reason to leave a database cleanup plugin active permanently.

WP-Optimize takes a slightly different approach, bundling revision cleanup with other database maintenance tasks (cleaning transients, spam comments, orphaned postmeta) and letting you schedule cleanups automatically.

Manual SQL (use with caution)

If you’re comfortable with SQL and have a database backup in place:

DELETE FROM wp_posts WHERE post_type = 'revision';
DELETE FROM wp_postmeta WHERE post_id NOT IN (SELECT ID FROM wp_posts);

The second query removes orphaned postmeta rows left behind after the revision rows are deleted. Always back up before running manual SQL deletions.

How Your Hosting Environment Affects This

The severity of revision bloat depends partly on your hosting environment. On shared hosting with slow disk I/O and limited database resources, a large wp_posts table has a more pronounced effect on query time than on a server with fast NVMe storage and adequate RAM.

Managed WordPress hosts that provision dedicated database resources — rather than sharing a database server across hundreds of accounts — keep query times lower even as table sizes grow. Hosts that include Redis object caching help further by serving frequently-accessed data from memory instead of hitting the database on every request.

Rocket.net includes Redis object caching, LiteSpeed-powered server infrastructure, and isolated database resources on every plan, which means the baseline database performance is substantially better than shared environments. That said, even on fast infrastructure, a bloated database with tens of thousands of revision rows creates unnecessary work — cleaning it up is a quick win regardless of your host.

A Practical Approach

The cleanest path forward for most sites:

1. Check your current revision count with a SQL query or WP-CLI
2. Set WP_POST_REVISIONS to 5 in wp-config.php to cap future revisions
3. Run a one-time cleanup to delete existing revisions, either via WP-CLI or a plugin like WP-Sweep
4. Back up first — this is permanent deletion

This takes less than an hour on most sites and produces an immediate reduction in database size. For a site with 10,000+ revisions, the table reduction can be significant — and the next time you run a database backup, the smaller export size makes that obvious.

Revisions are useful. Unlimited revisions, accumulating indefinitely across years of content edits, are rarely intentional — they’re just the default behavior running unchecked. Setting a reasonable limit and doing a one-time cleanup is one of the lower-effort, higher-impact maintenance tasks available to WordPress site owners.

---

If your WordPress site is running on hosting that’s already struggling to keep up, faster infrastructure makes every optimization more effective. Rocket.net is a managed WordPress host built on LiteSpeed servers with Redis caching, a global CDN, and developer-friendly tools — built for sites where performance is a real priority.