Every time you hit Update on a post, WordPress quietly files away a full copy of the old version. Do that a few dozen times on a page you fuss over, and you’ve got a few dozen complete copies sitting in your database — each one a full row in the same table your live content lives in. Most people never notice, because revisions are invisible from the front end and tucked behind a small link in the editor.
They’re genuinely useful. Revisions are the reason you can undo a bad edit from three weeks ago, see who changed what, or recover the paragraph a plugin conflict ate. But left completely unbounded — which is the out-of-the-box default — they’re also one of the quietest sources of database bloat on a busy WordPress site. A single heavily-edited page can carry hundreds of revision rows.
This guide walks through what revisions actually are, where they live, how to cap them so they stop piling up, and how to clean out the ones you’ve already accumulated without breaking anything.
What a Revision Actually Is
A revision is a snapshot of a post’s content, title, and excerpt at the moment you saved it. WordPress has stored them automatically since version 2.6, released in 2008, and the feature is on by default for posts and pages. The revamped revisions interface you use today — the slider and side-by-side diff — came later, in version 3.6. Under the hood, each revision is a real row in the wp_posts table with its post_type set to revision and its post_parent pointing back at the post it belongs to. That’s the key detail worth sitting with: revisions don’t live in some separate archive. They share the busiest table in your database with everything you actually publish.
There are two flavors, and people constantly mix them up. A revision is created every time you manually save or update a post, and each one is kept as its own row. An autosave is the draft the editor writes for you every sixty seconds while you type, so a browser crash doesn’t cost you an hour of work. Autosaves behave very differently from manual revisions, and that difference matters when you’re trying to figure out why one post has 40 stored versions.
Autosaves don’t pile up the way revisions do
The autosave interval is controlled by the AUTOSAVE_INTERVAL constant, which defaults to 60 seconds. But WordPress keeps only one autosave per post per author, and it overwrites that same row each cycle rather than stacking new ones. So a two-hour editing marathon doesn’t leave 120 autosave rows behind — it leaves one, updated over and over. The rows that genuinely accumulate are the manual ones: every time you or a co-author clicks Update, that’s a new permanent revision.
Because revisions are rows in wp_posts, they inflate the exact table WordPress queries most. A blog with 500 published posts and no revision limit can easily be storing several thousand revision rows — meaning your database is doing far more work than your visible content would suggest. It rarely breaks anything outright, but it’s dead weight on backups, migrations, and every query that scans that table.
The Default Is Unlimited, and That’s the Catch
Here’s the part that surprises people. Out of the box, WordPress keeps an infinite number of revisions per post. In core, the WP_POST_REVISIONS constant defaults to true, and internally that resolves to a value of -1 — no cap. Nobody deletes anything for you. Whatever you accumulate, you keep, until you take action.
On a small brochure site edited once a quarter, that’s a non-issue and honestly kind of nice. On a news site where five editors push updates all day, or a store where product descriptions get tweaked constantly, it adds up fast. The fix is one line in wp-config.php. You set a sensible ceiling and let WordPress prune old revisions automatically as new ones are created.
Capping revisions in wp-config.php
Add this above the /* That's all, stop editing! Happy publishing. */ line in your wp-config.php, which lives in your site’s root directory:
define( 'WP_POST_REVISIONS', 5 );Now WordPress retains the five most recent revisions for each post and quietly drops older ones as you keep editing. Five is a reasonable default for most sites — enough history to undo real mistakes, not so much that it becomes a landfill. You can go higher on content you revise heavily, or lower if you barely touch published posts. To turn revisions off entirely, set the value to false or 0:
define( 'WP_POST_REVISIONS', false );I’d think twice before disabling them completely, though. The one time you desperately want a revision is the time you didn’t keep any, and the storage cost of a modest cap is trivial next to that.
Different limits for different content
A single site-wide number is fine for most people, but WordPress lets you get more surgical. The wp_revisions_to_keep filter overrides the constant on a per-post basis, so you can keep 20 revisions on long-form articles and 2 on short product blurbs:
add_filter( 'wp_revisions_to_keep', function( $num, $post ) {
if ( 'product' === $post->post_type ) {
return 2;
}
if ( 'post' === $post->post_type ) {
return 20;
}
return $num;
}, 10, 2 );There’s also a per-post-type variant, wp_{$post_type}_revisions_to_keep, which overrides both the constant and the general filter. And revisions only apply to post types that declare support for them, so a custom post type that never opted in won’t store any in the first place.
Setting WP_POST_REVISIONS to a number doesn’t retroactively delete anything. It caps future growth — old revisions above the limit get pruned only as each post is edited again. Posts you never touch again keep their full pile until you clean them out manually. Capping and cleaning are two separate jobs.
Cleaning Out the Revisions You Already Have
Setting a cap fixes tomorrow. It does nothing about the thousands of rows you’ve built up over years of editing. To reclaim that space you have to delete existing revisions, and there are a few ways to do it depending on how comfortable you are on the command line.
Restoring and browsing revisions first
Before you delete anything, know how to use the feature you’re pruning. In the block editor, open a post and look for the revisions link in the Post panel of the settings sidebar — it shows a count, like “12 Revisions.” Click it and you get a slider with a side-by-side diff: additions highlighted in one color, deletions in another, author and timestamp for each save. Drag to any point in history and hit Restore This Revision to roll the post back. That’s the whole reason revisions exist, and it has saved more than one afternoon of rewritten work.
The WP-CLI approach
If you have terminal access, WP-CLI is the cleanest way to see what you’re dealing with. You can count every revision row on the site with a single command:
wp post list --post_type=revision --format=countCore WP-CLI doesn’t ship a dedicated revisions cleanup command, but there’s a well-maintained community package, wp-cli/wp-cli-revisions-command or the popular trepmal/wp-revisions-cli, that adds wp revisions list, wp revisions clean, and wp revisions dump. Once installed, cleaning everything down to your configured limit is one line:
wp revisions cleanWithout a third-party package you can still delete revisions using core commands by listing the revision IDs and passing them to wp post delete. Whichever route you take, WP-CLI is far safer than raw SQL because it goes through WordPress’s own deletion logic rather than reaching into the database directly.
The database approach, and why to be careful with it
You’ll find plenty of tutorials that tell you to run a raw DELETE FROM wp_posts WHERE post_type = 'revision' in phpMyAdmin. It works, and it’s fast, but it’s also the riskiest option on the list. A direct delete skips WordPress entirely, which means it won’t clean up related rows in wp_postmeta (and potentially other tables) that reference those revisions, and a typo in the WHERE clause can wipe live content instead. If you go this route, take a full database backup first — a real one you’ve confirmed you can restore, not just a hope. Better yet, use a maintenance plugin like WP-Optimize or the WP-CLI packages above, which delete revisions the way WordPress expects.
On one site we cleaned up, a plugin conflict had corrupted the live copy of the homepage and nobody could figure out when. The revision history made it obvious: a bad save three days earlier, timestamped and diffed against the good version right before it. One click restored it. Had that site disabled revisions to “save space,” the only fix left would have been the backups — and this was a site whose backups nobody had ever tested. Revisions aren’t just clutter; sometimes they’re the fastest path back to a working page.
A Sensible Revisions Policy
You don’t need to obsess over this. A good setup is boring and mostly hands-off. Set WP_POST_REVISIONS to something like 5 or 10 in wp-config.php so growth is bounded going forward. Do one cleanup pass of the backlog with WP-CLI or a reputable maintenance plugin. Then leave it alone and let the cap do its job.
If your site is large or collaborative, lean toward a slightly higher limit — the extra safety is worth more than the handful of megabytes it costs. If you run a small site you rarely edit, a low cap or even the default unlimited setting is genuinely fine; you’ll never accumulate enough to matter. The mistake isn’t picking the wrong number. It’s not knowing the setting exists and discovering years later that a single page is carrying 300 copies of itself.
Where revisions fit in the bigger cleanup picture
Revisions are one line item in overall database health, alongside expired transients, orphaned post meta, spam comments, and trashed posts that were never emptied. Capping revisions and clearing the backlog is a good first move because it’s low-risk and often reclaims the most space per minute of effort. If you want the full picture of what’s weighing your database down and how to trim it safely, that’s a whole topic of its own.
Frequently Asked Questions
A tidy database is one you never have to think about. If your revision count has quietly climbed into the thousands, cap it, clear it once, and move on.
Built by amplifi.studio — see also The Hidden Weight Slowing Your Site: A WordPress Database Cleanup Guide.