WordPress Revisions Are Not a Backup

The feature that quietly convinces people they're covered

Open the editor on almost any WordPress post or page and you'll see it in the sidebar: a revision count, sometimes climbing into the dozens or hundreds on a page that's been edited a lot. It looks like protection. Every change saved somewhere, available to roll back to. For a lot of site owners, that sidebar number is the quiet reason they never got around to setting up a real backup — "WordPress already keeps my old versions, doesn't it?"

It does, in a narrow sense. It just doesn't do it for the reason most people assume, and it stops covering you long before an actual disaster does.

What a revision actually is

Per the WordPress.org documentation on revisions, WordPress core saves a new revision every time a post or page is updated, plus an autosave roughly every 60 seconds while you're actively editing a draft. Each revision is a full copy of that post's content, title, and excerpt — not a diff of what changed, which is why a heavily-edited page can accumulate a surprising number of rows fast.

Revisions live in the same database table as your actual posts, wp_posts, tagged with post_type = 'revision' and a post_parent pointing back at the post they belong to. There's no separate "revisions" table, and no separate storage tier. They're just more rows in the table that also holds every published post, page, and piece of content on the site.

What revisions cover, and what they never touch

Revisions exist to answer one question: what did this specific post or page say before my last few edits? That's genuinely useful. A developer accidentally deletes three paragraphs, a client reverts an edit they didn't mean to publish, or someone just wants to see how a headline read two drafts ago — revisions handle all of that, instantly, from inside the editor, with no restore process at all.

What revisions do not cover:

• Anything outside the wp_posts table. Your theme, your plugins, your uploaded media, and every other database table — options, users, WooCommerce orders, form submissions — are completely untouched. Revisions track edits to one piece of content. Nothing else on the site.
• A deleted post or page. If a post is permanently deleted rather than edited, its revisions go with it. There's no separate revision archive that survives the parent post.
• A hacked, corrupted, or crashed site. Revisions live inside the same database as everything else. If that database is compromised, wiped, or the server it's on disappears, the revisions disappear with it — they offer zero protection against the exact scenarios a backup exists for.
• A plugin or theme update gone wrong. Revisions don't snapshot your plugin files or your theme files at all, so a bad update that breaks the site functionally has nothing in the revision history to roll back to.

That list is the actual gap. Revisions protect the words on one page. A backup protects the site.

Where revisions become a real database problem

By default, WordPress keeps revisions forever, with no limit. On a site that gets edited often — a news site with daily updates, a WooCommerce store with product descriptions that get tweaked constantly, or a content team that drafts in WordPress itself rather than elsewhere — that default adds up. A single page that's been through 200 edits over a couple of years is carrying 200 full copies of its own content in wp_posts, most of them never looked at again.

Three things get worse as that table grows:

• Database backup size. Every revision row is dead weight in a wp db export or any other database dump — bytes that have to be exported, compressed, transferred, and stored on every single backup run, for content nobody will ever restore.
• Query performance. Queries against wp_posts that aren't carefully scoped to post_type = 'post' can end up scanning through revision rows too. On a large, bloated table, that shows up as a slower admin screen and slower front-end queries that touch post data.
• Restore time. A database restore has to write every row back in, revisions included. A table padded with years of unused revisions takes measurably longer to import than the same site's actual content would on its own.

None of this is a WordPress bug. It's a reasonable default — unlimited revisions — that was never built with the assumption that a site would run for years without anyone pruning the table.

How to limit revisions going forward

The fix for new revisions is a single line in wp-config.php, placed above the line that says "That's all, stop editing":

define('WP_POST_REVISIONS', 10);

That caps every post and page at 10 saved revisions. Once a post's 11th revision is saved, WordPress automatically deletes its oldest one to stay at the limit. Ten is a reasonable starting point for most sites — enough history to recover from a bad editing session, not so much that a frequently-edited page accumulates hundreds of rows nobody will use.

Two related settings worth knowing about in the same file:

• define('WP_POST_REVISIONS', false); turns revisions off entirely. This is a reasonable choice for a site with one careful editor and no history of accidental overwrites, but it removes the quick in-editor undo entirely — there's no warning when you disable it, and no revisions to fall back on afterward.
• define('AUTOSAVE_INTERVAL', 120); changes how often WordPress autosaves a draft while you're actively writing (default 60 seconds). A longer interval means fewer autosave revisions piling up during one long editing session, at the cost of losing slightly more unsaved work if your browser crashes mid-edit.

Changing WP_POST_REVISIONS only affects revisions saved from that point forward. It does nothing to the ones already sitting in the database — that's a separate cleanup step.

Cleaning up the revisions already in your database

For existing bloat, there are two practical paths, depending on how comfortable you are working directly with the database.

Plugin route, no SQL required: a database-optimization plugin like WP-Optimize or Advanced Database Cleaner can scan for revision rows and delete them in bulk, with a preview of how many rows and how much space will be freed before you confirm. This is the lower-risk option for most site owners, since it runs through WordPress's own cleanup routines rather than raw queries.

Direct SQL, for anyone comfortable with WP-CLI or phpMyAdmin:

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';

That query removes every revision row along with its associated term relationships and postmeta, so you're not left with orphaned metadata pointing at a post that no longer exists. If you have WP-CLI access, the equivalent one-liner is simpler and safer to run repeatedly:

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

Either way, there's a rule worth following before running a bulk delete against production data: take a verified backup first. Deleting revisions is routine maintenance, not a risky operation in itself, but "run a bulk DELETE against the live database" is exactly the kind of step that deserves a fresh, tested restore point sitting there first, on the rare chance something else in the query goes sideways.

Revisions, autosaves, and trashed posts aren't the same cleanup job

Revisions get most of the attention, but two related categories bloat wp_posts the same way and are worth clearing in the same pass:

• Auto-drafts — WordPress creates a blank auto-draft post every time someone opens the "Add New" screen, even if they never type anything and never publish. Abandoned auto-drafts accumulate the same way unused revisions do.
• Trashed posts — deleted posts sit in the trash, not actually removed from the database, until WordPress's default 30-day trash-emptying cron runs (or until you empty it manually). A large trash folder is still taking up space in the same table.

Most database-optimization plugins clear all three — stale revisions, old auto-drafts, and expired trash — in a single pass, which is usually the more efficient way to approach this than running three separate cleanups.

Where backup actually fits

None of the above replaces a backup, and that's the point worth sitting with. Revisions are a content-editing convenience that happens to live in the same table as everything else your site depends on. Limiting or cleaning them is good database hygiene — it shrinks your backup size, speeds up queries, and makes restores faster. It does not give you a way to recover from a hacked site, a failed plugin update, a deleted media library, or a server that's gone entirely.

That's a separate, deliberate layer: a scheduled, verified, off-site copy of the entire site — database and files both — that exists independently of whatever happens to the live server. What a WordPress backup actually is covers that distinction in full, and why a database backup is only half a website covers the other half of the gap — the files a leaner, revision-free database export still won't capture on its own. See how BackupYourSite's backups work if you want the database-plus-files, off-site version of this covered on a schedule rather than run by hand.

Frequently Asked Questions

Do WordPress revisions count as a backup?

No. Revisions only track edits to the content of a single post or page — the title, body, and excerpt. They don't cover your theme, plugins, media files, other database tables, or anything about the site outside that one piece of content. A backup covers the entire site; revisions cover one post's edit history.

How many revisions does WordPress keep by default?

Unlimited, unless you've configured a limit. WordPress core keeps every revision ever saved for a post, with no automatic trimming, until you set WP_POST_REVISIONS in wp-config.php or clean up existing revisions manually.

Will limiting revisions make my site faster?

It can help, though the effect depends on how bloated the wp_posts table already is. A table carrying years of unused revisions makes database backups larger and can slow down queries that aren't scoped cleanly to actual posts. Limiting new revisions and cleaning out old ones is routine maintenance, not a guaranteed performance fix on its own.

Is it safe to delete all my WordPress revisions?

Generally yes — revisions are a convenience for undoing recent content edits, not data you need for anything else. The one thing to check first is whether you or an editor are actively relying on an old revision to recover a specific past draft. Take a database backup before running a bulk delete, the same precaution worth taking before any direct database change.

Does disabling revisions entirely cause any problems?

The main trade-off is losing the quick in-editor undo for content changes — if someone overwrites a paragraph by mistake, there's no revision to roll back to. For most sites, setting a reasonable limit like 10 is a better balance than disabling revisions outright.