How to Limit WordPress Post Revisions and Shrink Database Size

The first time I noticed revision bloat, it wasn’t during a speed test. It was during a backup. My database export kept getting bigger, even though I hadn’t added that much content. When I finally looked closer, I found posts with 40, 60, sometimes 100+ revisions.

If you want to limit WordPress revisions without breaking anything, the good news is you can do it with a couple of safe settings, plus a cleanup pass to remove old leftovers. I’ll walk through what revisions really are, how they differ from autosaves, and how I reduce database size in a way that still respects real editorial work.

Revisions vs autosaves, what’s actually filling your database?

WordPress revisions are full snapshots of a post or page taken when you click Update (and sometimes when editors trigger a save through the block editor). Each revision becomes its own row in the wp_posts table with post_type = 'revision'. If you run a busy blog, that table can start to feel like a junk drawer.

Autosaves are different. WordPress uses autosave as a safety net if your browser crashes or your connection drops. In modern WordPress (including current 2026 setups), autosaves often look like revisions in the database, but WordPress treats them differently. Typically, autosave keeps a limited “latest safety copy” per post (and often per user), not an endless chain.

Here’s why that matters: limiting revisions reduces long-term buildup, but it doesn’t stop autosave from doing its job. That’s what you want. I still like having autosave around, because it saves me from dumb mistakes.

Revisions help when:

• You overwrite a paragraph and regret it later.
• A client says, “Can we go back to last Tuesday’s version?”
• Multiple authors edit the same post over a week.

On the other hand, too many revisions can slow admin screens, increase backup time, and make migrations take longer. If you’ve ever opened a post and seen a huge Revisions count, you’re not alone. This write-up on trimming WordPress post revisions carefully matches what I see on older sites that were never tuned.

How I limit WordPress revisions safely (without wrecking workflows)

Before I change anything, I do two things every time: I take a full backup, and I test on staging if the site earns money. Revisions touch content history, so I don’t gamble with production.

You have two reliable ways to limit revisions:

Option A: Set WP_POST_REVISIONS in wp-config.php

This is the blunt, effective setting. Add it to wp-config.php (above the line that says “That’s all, stop editing!”).

• Keep a fixed number: define( 'WP_POST_REVISIONS', 5 );
• Disable revisions (rarely my first choice): define( 'WP_POST_REVISIONS', false );

In practice, I usually set 3 to 10. For a solo blogger, 3 or 5 feels fine. For a multi-author site, 10 can be safer.

Option B: Use a filter for more control

If you want different limits per post type, a filter is better. Add this to a small custom plugin or your theme’s functions.php:

• Same limit everywhere: add_filter( 'wp_revisions_to_keep', function( $num, $post ) { return 5; }, 10, 2 );
• Different limits by type: add_filter( 'wp_revisions_to_keep', function( $num, $post ) { return ( $post->post_type === 'page' ) ? 3 : 10; }, 10, 2 );

This is my go-to when pages are “evergreen” and posts are edited more often.

To make the tradeoffs obvious, here’s how I think about the options:

Method	Best for	What to watch out for
WP_POST_REVISIONS constant	Simple sites, quick wins	Same limit for everything
wp_revisions_to_keep filter	Mixed content types, teams	Needs careful placement and testing
Disabling revisions	Very controlled content	Harder rollbacks, less editorial safety

Limiting revisions changes your editorial safety net. That’s the real cost. If you publish news, legal content, or client work with approvals, don’t set the number too low just to save megabytes.

Shrink database size by deleting old revisions (WP-CLI first, SQL last)

Limiting revisions stops future buildup, but it won’t remove the mountain you already have. For that, I clean up old revisions. I strongly prefer WP-CLI because it’s repeatable and easier to undo if you have a backup.

If you’re comfortable in the terminal, this pairs well with my guide on optimize WordPress database with WP-CLI.

My safe WP-CLI cleanup flow

1. Export a fresh backup: wp db export
2. Count revision posts: wp post list --post_type=revision --format=count
3. Delete revisions (this removes all revisions): wp post delete $(wp post list --post_type=revision --format=ids) --force
4. Optimize tables after the purge: wp db optimize

That third command is aggressive, so I only run it when I’m sure the revision history isn’t needed. On team sites, I’ll often limit revisions first, then wait a few weeks before deleting old revisions. That gives authors time to notice if they relied on long revision trails.

If you’re not sure, don’t delete everything at once. Limit revisions now, then schedule a cleanup after your next content cycle.

Optional SQL cleanup (only if you really know what you’re doing)

SQL is fast, but it’s also the easiest way to ruin your day.

Strong warning: run SQL only on a staging copy first, and only after a verified backup. Also, replace wp_ with your real table prefix.

A common purge query looks like this: DELETE FROM wp_posts WHERE post_type = 'revision';

After that, some people also remove orphaned meta rows. That can be helpful, but it can also delete things you didn’t mean to touch if you write the query wrong. I won’t run orphan cleanup SQL on production unless I’ve tested the exact query on staging.

If you want more database size ideas beyond revisions, this list of reduce WordPress database size methods is a good overview (spam, transients, and leftovers also add up).

My practical checklist and a maintenance cadence that sticks

Once revisions are under control, keeping the database lean feels more like brushing your teeth than doing a big renovation.

Here’s the checklist I use:

• Backup first (files and database), then confirm you can restore.
• Test on staging if the site has sales, leads, or heavy traffic.
• Set a revision cap using WP_POST_REVISIONS or wp_revisions_to_keep.
• Keep autosaves enabled, they’re your crash helmet.
• Clean old revisions with WP-CLI when you’re ready.
• Optimize tables after big deletes.
• Agree on a revision number with your editors, so nobody feels surprised later.

For cadence, I like this:

• Monthly: check revision counts and database size.
• Quarterly: delete old revisions (if your workflow allows it).
• Before major redesigns or migrations: do a cleanup to speed up backups and transfers.

Conclusion

Revisions are helpful, but unlimited revisions are like keeping every rough draft you ever wrote. Once I started to limit WordPress revisions, my backups got smaller and my database stayed calmer over time. Set a sensible cap, protect autosaves, then clean out the backlog when you’re confident you won’t need it. If you want a simple next step, set the limit today and schedule the cleanup for your next maintenance window.