What are WordPress post revisions, really?

WordPress post revisions are historical versions of your content that WordPress stores so earlier edits can be reviewed and restored.

That sounds simple, but revisions are frequently misunderstood.

They are sometimes described as:

automatic backups of your posts

or:

duplicate posts that WordPress keeps creating

Neither description is quite accurate.

A revision is a specific WordPress content record associated with another post. It exists inside the same content architecture as posts and pages, has its own database row, points back to a parent post and preserves revision-supported fields from an earlier state.

WordPress also stores autosaves using the revision system, but autosaves and normal revisions have different purposes and different retention behavior.

The practical model is:

Current post
→ the version currently being edited or published

Revision
→ historical version created from an earlier save

Autosave
→ temporary recovery version created while editing

This guide explains what WordPress post revisions really are, where they are stored, what they contain, how they differ from autosaves, when WordPress creates them, how restoration works, why they can increase database size and how to choose a sensible revision-retention policy.

What is a WordPress post revision?

A WordPress revision is a previous version of revision-enabled content.

WordPress’s official Revisions documentation describes the revision system as a way to preserve saved versions of posts and pages so editors can inspect what changed and restore an earlier version when necessary.

Imagine a page containing:

Version 1
Original homepage copy

Version 2
Updated introduction

Version 3
New services section

Version 4
Current published page

Depending on the site’s revision settings, WordPress can retain earlier versions so an editor can compare or restore them later.

Revisions are actual WordPress post records

They are not separate SQL backup files and they are not stored in a special revisions table.

WordPress stores revisions in the same posts table used for other content.

On a default installation, that is normally:

wp_posts

A normal published post might have:

post_type = post
post_status = publish

while one of its revisions uses:

post_type = revision
post_status = inherit

The official WordPress revision documentation confirms that revisions are stored as child records of the content they belong to.

A revision points back to its parent post

Suppose the original post has:

ID = 500

A revision may have:

ID = 742
post_parent = 500
post_type = revision
post_status = inherit

Conceptually:

Post 500
├── Revision 650
├── Revision 681
├── Revision 704
└── Revision 742

The revisions remain associated with the original post through the parent relationship.

What does a WordPress revision actually store?

By default, WordPress tracks changes to several important post fields.

The official revision documentation identifies fields such as:

• title;
• content;
• excerpt;
• author-related revision information.

Internally, WordPress determines revision-supported fields through its revision system rather than duplicating every possible field in the post record blindly.

The Core revision implementation is documented in the wp-includes/revision.php reference.

Post meta can also participate in revisions

Modern WordPress supports revisioned post meta when metadata has been registered appropriately for revision support.

Core contains functions such as:

wp_save_revisioned_meta_fields()
wp_restore_post_revision_meta()

documented in the WordPress revision source reference.

This matters because modern WordPress content can extend beyond:

post_title
post_content
post_excerpt

Plugins and custom applications may depend on additional metadata that also needs meaningful version history.

Revisions are not complete snapshots of the whole website

A post revision does not contain:

• the entire WordPress database;
• plugin files;
• theme files;
• Media Library files;
• site-wide options;
• users;
• the complete state of every plugin.

It is therefore incorrect to treat revisions as an alternative to backups.

A revision solves:

I changed this piece of content
and need an earlier version.

A backup solves much broader problems such as:

database damaged
server failed
files deleted
site compromised
migration failed

For broader recovery workflows, TheOneWP Backup Manager addresses complete, database-only and files-only backups rather than individual content history.

When does WordPress create revisions?

WordPress can create a revision as content is deliberately updated.

The Core wp_save_post_revision() function creates a revision from the current version of a post.

Its documentation explains an important detail: when a post is updated, the revision system preserves the relevant previous state while the current post remains the primary content record.

The result is a history such as:

current post
↓
revision
revision
revision
revision

WordPress does not necessarily save meaningless duplicate revisions forever

Core includes checks designed to avoid saving unnecessary revisions when the revisionable fields have not meaningfully changed.

Revision creation should therefore not be thought of as:

every request
=
new revision

or:

every second in the editor
=
new permanent revision

Autosaves are not the same as normal revisions

This distinction matters enormously.

WordPress autosaves exist primarily to protect work while someone is actively editing.

Normal revisions exist primarily to preserve historical saved versions.

The simplest distinction is:

Revision
→ content history

Autosave
→ editing recovery

For the dedicated comparison, see WordPress Autosave vs. Post Revisions, Explained.

Autosaves are stored as a special kind of revision

This is where the terminology becomes slightly confusing.

At the database architecture level, autosaves participate in the revision system.

The official WordPress Revisions documentation describes autosaves as a special type of revision.

So these two statements can both be true:

Autosaves and revisions serve different purposes.

Autosaves are stored through the revision architecture.

Autosaves do not accumulate like normal revisions

The current WordPress documentation states that there is a maximum of one autosave per user for a given post.

When that user produces a newer autosave, the previous autosave is overwritten.

On a multi-user editing environment, different users can have their own autosave associated with the same post.

That means the common claim:

WordPress creates another database row
every 60 seconds forever

is wrong.

Autosaves do not overwrite published content

The autosave is preserved separately.

If:

• the browser crashes;
• the computer loses power;
• the connection fails;
• the editing session is interrupted;

WordPress may detect a newer autosaved version and offer a recovery path.

Autosave frequency is controlled separately

The autosave interval and revision-retention limit are different settings.

WordPress documents:

AUTOSAVE_INTERVAL

in its wp-config.php documentation.

For example:

define( 'AUTOSAVE_INTERVAL', 180 );

would configure an autosave interval of 180 seconds in contexts using that setting.

How to Change the WordPress Autosave Interval covers that configuration separately.

TheOneWP Autosave Interval provides a configurable interface for the same broader autosave policy.

Do not change autosave frequency because you want fewer revisions

These solve different problems:

AUTOSAVE_INTERVAL
→ how frequently work is automatically protected

WP_POST_REVISIONS
→ how many historical revisions are retained

Reducing autosave frequency is not the proper way to manage long-term revision history.

Revisions and post locking are also separate

WordPress post locking helps coordinate concurrent editing when multiple users can edit the same content.

Revisions answer:

What did this content look like earlier?

Post locking answers:

Who is editing this content now?

Autosave answers:

Can I recover unsaved work from this editing session?

See WordPress Post Locking Explained for the collaborative-editing side of the system.

How do you view revisions in WordPress?

For revision-enabled content with revision history, WordPress exposes the revision count through the post or page settings.

WordPress 7.0 introduced an updated revisions experience.

The current WordPress revisions documentation explains that clicking the revision count in WordPress 7.0 opens the newer revisions screen.

The WordPress 7.0 revisions screen

The updated interface provides a visual comparison of changes and a timeline for moving through saved versions.

Changes can be identified as:

• inserted content;
• deleted content;
• changed content.

The interface allows an editor to move through revision history and restore the selected version.

The classic revisions interface still exists

WordPress 6.9 and earlier used the classic revisions screen by default.

WordPress 7.0 retains access to the classic comparison interface as an alternative.

The classic screen allows:

• moving between versions;
• side-by-side comparison;
• comparing two revisions;
• restoring a selected version.

Restoring a revision does not erase history in the simplistic way people expect

When you restore an old revision, WordPress uses the revision’s data to update the current post.

The workflow is conceptually:

Current version
Version D

Choose older revision
Version B

Restore
↓

Current post becomes based on Version B

The revision system remains a history mechanism rather than simply swapping database rows.

A restored revision becomes the basis of the current content

This is important when someone thinks:

Restore Revision 5
→ permanently delete everything after Revision 5

That is not the useful mental model.

Think:

Take data from Revision 5
↓
apply it to current post

Developers can retrieve revisions programmatically

WordPress provides:

wp_get_post_revisions()

The official wp_get_post_revisions() documentation describes the function as returning revisions belonging to a specified post.

For example:

$revisions = wp_get_post_revisions(
    $post_id
);

The result can be used by plugins and custom administration interfaces that need revision information.

WordPress also exposes revisions through the REST API

The official Post Revisions REST API reference documents endpoints for retrieving and deleting revision records where the authenticated user has appropriate permission.

This is relevant for:

• custom editorial applications;
• headless WordPress systems;
• custom administration interfaces;
• external content-management tooling.

Which post types support revisions?

Revisions are tied to post-type feature support.

WordPress post types can register support for:

revisions

The official add_post_type_support() documentation lists revisions as a supported post-type feature.

Custom post types do not automatically behave identically

A custom post type may support:

title
editor
thumbnail
revisions

or it may omit revisions completely.

For example:

register_post_type(
    'project',
    array(
        'supports' => array(
            'title',
            'editor',
            'revisions',
        ),
    )
);

would declare revision support as part of the post type configuration.

For the broader content architecture, see WordPress Post Types vs. Custom Post Types.

How many revisions does WordPress keep?

By default, WordPress keeps an unlimited number of revisions for content types that support revisions.

The Core wp_revisions_to_keep() documentation confirms that the default is effectively unlimited.

The effective limit can be controlled with:

WP_POST_REVISIONS

WP_POST_REVISIONS can have several values

The official WordPress documentation defines the behavior approximately as:

true
→ unlimited revisions

-1
→ unlimited revisions

false
→ disable normal revisions

0
→ disable normal revisions

positive integer
→ keep that number of revisions

Example: keep five revisions

In wp-config.php:

define( 'WP_POST_REVISIONS', 5 );

This establishes a retention policy of five ordinary revisions for supported posts, with autosaves remaining a separate consideration.

Example: disable normal revisions

define( 'WP_POST_REVISIONS', false );

This disables normal revision storage.

However, WordPress documentation makes an important distinction: autosave behavior is not simply equivalent to normal revision retention.

Disabling revisions does not mean “no autosaves exist”

The current revision documentation describes:

WP_POST_REVISIONS = false
or
WP_POST_REVISIONS = 0

as disabling normal revisions while autosave recovery remains a separate mechanism.

This is another reason not to use the words:

revision
autosave

interchangeably.

The revision limit can also be filtered programmatically

WordPress exposes:

wp_revisions_to_keep

for developers who need dynamic revision-retention logic.

The wp_revisions_to_keep() reference documents this filtering mechanism.

You can apply different policies to different content

For example:

Blog posts
→ 10 revisions

Landing pages
→ 30 revisions

Machine-generated records
→ 2 revisions

when the site’s architecture and editorial workflow justify different policies.

The revision limit is not necessarily a bulk-cleanup command

This distinction is easy to miss.

Suppose the database already contains:

80 revisions
for one post

and you change:

WP_POST_REVISIONS

to:

5

That configuration controls the retention policy WordPress applies as revision processing continues.

It should not be treated as a guaranteed instruction saying:

immediately scan the entire database
and delete every historical revision
until only five remain

Revision pruning occurs as WordPress saves revisions

The Core wp_save_post_revision() implementation applies the configured retention rules and can delete older revisions that exceed the limit.

If the site already contains years of historical revision data, separate cleanup may still be appropriate.

Why do revisions make the database larger?

Because each revision is an additional post record.

Imagine:

5,000 posts
×
20 retained revisions
=
100,000 revision rows

Those rows exist in addition to:

• current posts;
• pages;
• attachments;
• custom post types;
• other WordPress content records.

For a deeper look at the table itself, see Optimizing the WordPress Posts Table.

Revision size depends heavily on the content

A revision of:

300-word blog post

is very different from a revision of:

large page-builder document
containing extensive serialized or structured content

A site with heavily edited visual-builder pages can therefore accumulate considerably more revision data than a simple editorial blog.

Metadata can also contribute

When revision-supported metadata is involved, revision history may include associated versioned meta information as well.

The relevant question is not merely:

How many revision rows exist?

but also:

How large is each revision?
How frequently is content edited?
Which metadata is revisioned?
How much history is useful?

Are WordPress revisions bad for performance?

Not automatically.

The existence of revisions does not mean WordPress loads every historical copy whenever a public post is viewed.

A frontend request for:

/my-article/

does not normally need to retrieve:

Revision 1
Revision 2
Revision 3
Revision 4
Revision 5
...

before displaying the current post.

A larger database is not automatically a slow database

Relational databases are built to manage large numbers of rows.

Performance depends on factors such as:

• query patterns;
• indexes;
• database resources;
• table size;
• metadata architecture;
• plugin behavior;
• administrative queries.

See WordPress Database Bloat Explained for the distinction between legitimate data growth and unnecessary database accumulation.

Very large revision histories can still have costs

Excessive revision accumulation can affect:

• database storage;
• backup size;
• migration size;
• database exports;
• maintenance operations;
• some revision-related administration queries;
• cleanup operations.

So the correct conclusion is not:

Revisions destroy performance.

It is:

Revision history has a storage cost,
and retention should match the site's needs.

Revisions can be extremely valuable

Consider an editor who accidentally:

• deletes an important section;
• rewrites a page incorrectly;
• publishes incomplete copy;
• removes legal wording;
• overwrites another person’s changes.

Revision history may allow the earlier content to be recovered in seconds.

Multi-author sites benefit even more

When several people edit content, revisions can help answer:

• what changed?
• when did it change?
• which earlier wording should be restored?

Revisions are therefore part of the editorial safety system, not merely database clutter.

Revision history is not a complete audit log

This distinction is important.

A revision history helps compare versions of content.

It should not automatically be treated as a comprehensive compliance or security audit system recording every possible administrative action.

For example, revision history does not replace dedicated logging for:

• login events;
• plugin changes;
• role changes;
• configuration changes;
• file modifications;
• security events.

Should you disable WordPress revisions?

Usually, completely disabling them is a fairly aggressive choice.

The decision should be based on the editorial workflow rather than the vague idea that fewer rows must always be better.

A small business website

A site with occasional edits might use:

5–10 revisions per post

as a practical retention policy.

An editorial publication

A publication with multiple writers and frequent changes may benefit from:

20+
or significantly more revisions

depending on workflow requirements.

A page-builder website

Large page-builder revisions can consume substantial storage, but revision recovery may also be particularly valuable because recreating a complex page manually can be expensive.

A moderate limit is often preferable to complete removal.

Machine-generated content

For content that is regenerated automatically and has little editorial value, a smaller revision history may be appropriate.

Choose retention based on recovery value

A useful question is:

How many historical versions would we
realistically need to recover from?

Then compare that with:

How much database storage
does this history consume?

TheOneWP Post Revisions

TheOneWP Post Revisions provides an interface for controlling how many WordPress revisions are retained.

Instead of manually editing:

wp-config.php

for an ordinary retention policy, the module can establish a deliberate revision limit such as:

Keep the last 10 revisions

Revision retention and historical cleanup are different operations

This distinction should remain explicit:

Post Revisions
→ controls retention policy

Database Optimizer
→ can address historical cleanup

If the database already contains large quantities of obsolete revision data, TheOneWP Database Optimizer can target supported cleanup categories separately.

Inspect before cleaning

TheOneWP Database Manager can help inspect the underlying WordPress tables and determine whether revision records are actually a meaningful part of database growth.

A sensible sequence is:

measure revision volume
↓
decide retention policy
↓
create backup
↓
clean historical excess if appropriate
↓
apply future retention limit

Back up before large revision cleanup

Deleting thousands of historical records is a database maintenance operation.

Before broad cleanup, create a recoverable backup using an appropriate backup process such as TheOneWP Backup Manager.

Do not delete revisions with random SQL copied from the internet

You may encounter queries such as:

DELETE FROM wp_posts
WHERE post_type = 'revision';

That looks wonderfully efficient right up until related data, custom revision behavior or an unexpected plugin dependency makes the operation less simple than the query suggested.

WordPress provides revision-aware APIs and supported cleanup mechanisms for a reason.

Revision cleanup can involve related metadata

A revision can have associated post metadata.

Deleting rows directly from:

wp_posts

without understanding related data can leave unnecessary records behind or bypass hooks that WordPress-aware cleanup would execute.

Use WordPress APIs when developing revision tools

Core provides functions for operations such as:

wp_get_post_revisions()
wp_save_post_revision()
wp_delete_post_revision()
wp_restore_post_revision()

These allow custom tools to operate within WordPress’s revision model instead of treating revisions as anonymous rows.

Revisions during migrations

Revisions normally move with the WordPress database because they are part of the posts architecture.

That means a site containing:

20,000 current content records
+
180,000 revisions

will carry those revision records into the migration unless they are deliberately handled.

Large historical revision sets can therefore increase:

• SQL export size;
• transfer time;
• import time;
• backup size.

See Preparing a WordPress Database for Migration before combining database cleanup with a site move.

Do not start aggressive cleanup during the final migration window

If revisions need cleanup, investigate them before the cutover.

A safer process is:

inspect
↓
backup
↓
test cleanup
↓
verify site
↓
migrate

rather than:

site offline
↓
discover 300,000 revisions
↓
run untested DELETE query
↓
hope

Revisions in staging

Revision history can be useful on staging because it preserves the editorial history copied from production.

But a staging site can also generate additional test revisions that have no production value.

If staging will later be replaced or discarded, those records may not matter.

If database changes are going to be promoted back to production, however, revision behavior should be understood as part of the deployment strategy.

See WordPress Staging Site Best Practices for environment separation.

Revisions and the WordPress REST API

For supported post types, WordPress can expose revision endpoints through the REST API.

The official REST API Post Revisions reference documents operations such as retrieving and deleting revisions.

Access still depends on WordPress authentication and capabilities.

Revision endpoints are not automatically public editorial history

Do not assume that because a REST route exists, anonymous visitors can retrieve every historical version of private editorial content.

Permission checks remain part of the REST API architecture.

For the wider API security model, see WordPress REST API Security Basics.

Common misconceptions about WordPress revisions

“A revision is a full backup.”

No. It preserves selected historical content state, not the whole site.

“Every autosave creates another permanent revision.”

No. Autosaves have separate retention behavior and are overwritten per user for a given post.

“Revisions are stored in a separate revisions table.”

No. They are stored in the WordPress posts architecture with post_type = revision.

“Disabling revisions disables autosave.”

No. Revision retention and autosave behavior are separate controls.

“Setting the revision limit to five instantly deletes every older revision.”

Do not treat the configuration change as an immediate database-wide cleanup operation.

“Revisions always make the frontend slow.”

No. Public requests do not normally retrieve every historical revision simply to render the current post.

“More revisions are always better.”

No. Historical versions have value, but retaining unlimited history forever may be unnecessary for some sites.

“Fewer revisions are always better.”

No. Removing useful recovery history to save a modest amount of storage can be a poor tradeoff.

“I can safely delete revision rows directly.”

Direct SQL can bypass WordPress-aware cleanup and related data handling.

“Autosave interval controls revision count.”

No. Autosave timing and revision retention are separate settings.

How to audit revision usage on a WordPress site

Before changing anything, answer these questions:

• Which post types support revisions?
• How many revision records exist?
• How large is the posts table?
• How frequently is content edited?
• Does the site use a page builder?
• How valuable is historical content recovery?
• How many editors work on the site?
• Does custom metadata participate in revisions?
• Is the current revision limit unlimited?
• Are backups being affected materially by revision size?

Inspect revision count in the database carefully

A basic diagnostic query can count revision records:

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

This is useful for inspection.

Remember that:

wp_posts

may use a different table prefix on your installation.

Count is only the beginning

Finding:

50,000 revisions

does not automatically tell you whether there is a problem.

Compare that number with:

• total content volume;
• database size;
• editorial activity;
• backup requirements;
• revision value.

A practical revision-retention strategy

For many managed WordPress sites, a sensible process is:

1. Keep revisions enabled.
2. Measure existing revision volume.
3. Determine how much historical recovery the editors actually need.
4. Set a finite retention limit where appropriate.
5. Keep autosave settings separate.
6. Create a backup before historical cleanup.
7. Clean excessive old revisions only when there is a clear benefit.
8. Monitor database growth afterward.

Example policy for a small company website

Post revisions:
10

Autosave:
normal recovery interval

Historical cleanup:
remove obsolete excess after backup

Example policy for a busy editorial site

Post revisions:
30 or more

Autosave:
frequent enough for reliable recovery

Historical cleanup:
conservative

Reason:
editorial history has high value

Example policy for large page-builder pages

Post revisions:
moderate finite limit

Reason:
individual revisions can be large
but recovery is highly valuable

WordPress post revision checklist

• Confirm that the relevant post type supports revisions.
• Understand that revisions are stored as post records.
• Distinguish revisions from autosaves.
• Distinguish revisions from backups.
• Distinguish revisions from post locking.
• Check the current WP_POST_REVISIONS configuration.
• Check whether a plugin filters revision retention.
• Review the editorial workflow before changing limits.
• Check how many users edit content.
• Review whether custom post types support revisions.
• Review whether custom metadata is revisioned.
• Measure revision row count.
• Measure actual database size.
• Consider page-builder revision size.
• Consider backup and migration size.
• Keep enough revisions for realistic recovery.
• Do not disable revisions merely because they consume storage.
• Do not assume unlimited revisions are appropriate for every site.
• Do not confuse autosave frequency with revision retention.
• Do not use random direct SQL for production cleanup.
• Create a backup before mass revision deletion.
• Use WordPress-aware cleanup where possible.
• Test custom revision behavior on staging.
• Verify REST API permissions for custom revision integrations.
• Reassess retention as the site grows.

TheOneWP tools for revision management

Post Revisions

Post Revisions controls how many historical revisions WordPress retains.

Use it when the objective is:

future revision-retention policy

Autosave Interval

Autosave Interval controls how frequently WordPress automatically protects in-progress editor work.

Use it when the objective is:

editing recovery frequency

not revision-history size.

Database Optimizer

Database Optimizer can address supported historical database-cleanup categories when old revision data has accumulated beyond the site’s needs.

Database Manager

Database Manager can help inspect the underlying database before cleanup or optimization.

Backup Manager

Backup Manager provides the recovery layer that should exist before destructive revision cleanup.

Keep these systems separate

Post Revisions
→ historical versions

Autosave Interval
→ in-progress recovery timing

Database Optimizer
→ historical cleanup

Database Manager
→ database inspection

Backup Manager
→ broader recovery

Related guides

• How WordPress Post Revisions Work
• WordPress Autosave vs. Post Revisions, Explained
• WordPress Post Locking Explained
• WordPress Database Bloat Explained
• Optimizing the WordPress Posts Table
• Preparing a WordPress Database for Migration

Final recommendation

WordPress post revisions are historical content records, not full backups and not meaningless duplicate posts.

They live inside the normal WordPress post architecture:

current post
↓
revision children
↓
historical content states

Autosaves participate in that architecture but solve a separate problem: protecting work during an active editing session.

Keep those concepts separate:

Revision
→ history

Autosave
→ recovery

Post locking
→ editing coordination

Backup
→ site recovery

For most WordPress websites, completely disabling revisions is less useful than choosing a sensible finite retention policy.

A site with occasional edits may need only a modest history. A publication with multiple editors may benefit from considerably more. A page-builder site may require a balance between large revision records and the high value of being able to restore complex layouts.

Measure the actual revision footprint before treating it as a performance problem, create a backup before historical cleanup and use WordPress-aware mechanisms instead of deleting database rows blindly.

The right number of revisions is not zero, unlimited or any other universal value. It is the amount of content history that provides meaningful recovery value for the site’s real editorial workflow without retaining substantially more historical data than anyone is likely to use.