WordPress Autosave vs. Post Revisions, Explained

WordPress autosave vs. post revisions is an important distinction to understand because both systems preserve versions of content, but they solve different editing problems and follow different storage rules.

An autosave protects work that has not yet been intentionally saved.

A post revision preserves a historical version created through the normal content-saving process.

The simplest model is:

Autosave
→ recovery protection while editing

Post revision
→ historical version after a save or update

The terminology becomes slightly confusing because WordPress stores autosaves through the same revision architecture used for ordinary post revisions.

So these two statements are both true:

Autosaves and revisions
serve different purposes.

Autosaves are technically
a special type of revision.

This guide explains how WordPress autosaves and post revisions differ, how they are stored, when WordPress creates them, how many are retained, how recovery and restoration work, how WordPress 7.0 displays revision history, how custom post types and metadata interact with revisions and how to configure both systems without confusing autosave frequency with revision retention.

WordPress autosave vs. post revisions: the quick answer

The practical difference is:

AUTOSAVE

Created automatically
while editing

Primary purpose:
recover unsaved work

Typical frequency:
every 60 seconds

Retention:
maximum one autosave
per user per post


POST REVISION

Created from content saves
and updates

Primary purpose:
historical version recovery

Frequency:
depends on actual saves

Retention:
unlimited by default
unless configured otherwise

Autosaves protect the current editing session.

Revisions preserve content history across editing sessions.

What is WordPress autosave?

WordPress autosave automatically preserves editing progress while a user is working on supported content.

The purpose is to reduce lost work when something interrupts the editing session.

Examples include:

• the browser crashing;
• the computer losing power;
• the internet connection failing;
• a tab being closed unexpectedly;
• the editor becoming unresponsive;
• a session being interrupted before the user clicks Save.

WordPress can later detect that a newer autosaved version exists and provide a recovery path.

What is a WordPress post revision?

A revision is a stored historical version of revision-enabled content.

The official WordPress Revisions documentation describes the revision system as a way to preserve previous versions so editors can inspect changes and restore an earlier state.

A revision answers:

What did this content
look like earlier?

An autosave answers:

Can WordPress recover
work I had not deliberately
saved yet?

For a deeper treatment of the revision architecture itself, see What Are WordPress Post Revisions, Really?.

Autosaves are stored as a special type of revision

At the database level, autosaves participate in WordPress’s revision architecture.

Both normal revisions and autosaves use:

post_type = revision

and both are associated with the parent post.

This is why WordPress documentation can accurately describe autosaves as a special type of revision even though their purpose and retention behavior differ.

Revisions live in the posts table

Normal revisions are stored in the same posts table architecture used by ordinary WordPress content.

A standard installation therefore commonly contains records representing:

post
page
attachment
revision
navigation item
custom post types
...

inside the posts table.

A revision is linked back to its original post through:

post_parent

and uses:

post_type = revision
post_status = inherit

This architecture is documented in the official WordPress revisions documentation.

Autosaves are identified separately from normal revisions

WordPress provides:

wp_is_post_autosave()

for identifying whether a revision record represents an autosave.

The official wp_is_post_autosave() documentation shows that WordPress identifies autosave revisions through their revision naming structure.

It returns the parent post ID when the supplied revision is an autosave.

WordPress can also identify ordinary revisions

The related:

wp_is_post_revision()

function determines whether a post object or ID represents a revision.

See the official wp_is_post_revision() reference.

The current content is separate from its revisions

Consider a published article:

Post ID:
100

Current content:
Version C

Its historical records might be:

Revision 301
→ Version A

Revision 317
→ Version B

and the current editing session might also have:

Autosave 322
→ unfinished Version D

The conceptual structure becomes:

Revision A
Revision B
      ↓
Current Post C
      ↓
Autosaved work D

These are related records, but they represent different states.

Autosaves do not overwrite published content

An autosave is stored separately from the published post.

If a user begins editing:

Published Version A

and WordPress creates an autosave containing:

Draft Version B

the public site does not automatically start displaying Version B.

The autosaved work remains separate until the normal publishing or update workflow commits the content.

How often does WordPress autosave?

The default WordPress autosave interval is:

60 seconds

The official WordPress wp-config.php documentation documents the:

AUTOSAVE_INTERVAL

constant.

WordPress Core defines the default as:

MINUTE_IN_SECONDS

when no custom value is configured.

You can change the WordPress autosave interval

For example:

define(
    'AUTOSAVE_INTERVAL',
    180
);

changes the interval to:

180 seconds
=
3 minutes

For the configuration process itself, see How to Change the WordPress Autosave Interval.

TheOneWP Autosave Interval provides a configurable interface for managing this behavior without manually maintaining the constant.

Autosaving every 60 seconds does not mean storing a new permanent row every 60 seconds forever

This is one of the most common misconceptions about WordPress autosaves.

A user editing one post for:

2 hours

with a:

60-second autosave interval

does not automatically produce:

120 permanently retained
autosave revisions

for that user.

WordPress keeps a maximum of one autosave per user per post

The current WordPress documentation states that there is normally a maximum of:

one autosave
per user
per post

When that same user produces a newer autosave, WordPress updates the autosaved state rather than accumulating an endless chain of autosaves.

Multiple users can have separate autosaves

This becomes important on collaborative sites.

Suppose:

Post ID 100

is edited by:

Alice
Bob

WordPress can maintain:

Alice autosave
+
Bob autosave

for that post.

The retention rule is therefore not:

one autosave total
per post

but:

one autosave
per user
per post

wp_get_post_autosave() retrieves autosaved content

WordPress provides:

wp_get_post_autosave()

for retrieving autosaved data.

The official wp_get_post_autosave() documentation allows code to retrieve either:

• the latest autosave for a post;
• the autosave associated with a specific user.

For example:

$autosave = wp_get_post_autosave(
    $post_id,
    $user_id
);

Autosave frequency and revision retention are independent settings

This is the central distinction.

AUTOSAVE_INTERVAL
→ how frequently editing work
is automatically protected

WP_POST_REVISIONS
→ how many normal historical
revisions WordPress retains

Changing one does not configure the other.

A longer autosave interval does not reduce the revision limit

Suppose you configure:

AUTOSAVE_INTERVAL = 300

That means WordPress attempts autosave activity less frequently during editing.

It does not mean:

keep fewer revisions

A revision limit does not make autosave less frequent

Likewise:

WP_POST_REVISIONS = 5

does not mean WordPress autosaves every five minutes.

It means WordPress retains a limited number of normal historical revisions according to its revision-retention logic.

What is the default revision limit?

By default, WordPress keeps:

unlimited normal revisions

for post types that support revisions.

The official wp_revisions_to_keep() documentation states that the default is an unlimited number of revisions.

WP_POST_REVISIONS controls the global revision policy

The constant can be configured in:

wp-config.php

For example:

define(
    'WP_POST_REVISIONS',
    10
);

This tells WordPress to retain up to ten normal revisions according to the revision-retention system.

WP_POST_REVISIONS supports several modes

true
→ normal revisions enabled
→ unlimited by default

-1
→ unlimited revisions

false
or
0
→ normal revisions disabled

positive integer
→ maximum normal revisions retained

Autosaves remain a separate special case.

Disabling normal revisions does not disable autosave

This is another important distinction.

If you configure:

define(
    'WP_POST_REVISIONS',
    false
);

WordPress can still maintain the autosave used to protect current editing work.

The official WordPress revisions documentation explicitly distinguishes normal revision storage from the one-autosave-per-user behavior.

Why does WordPress retain autosave when revisions are disabled?

Because the two systems solve different problems.

Revision history disabled
→ no long-term historical versions

Autosave retained
→ current editing recovery
still available

Without this separation, disabling revision history would also remove an important editor-recovery mechanism.

How are normal revisions created?

WordPress provides:

wp_save_post_revision()

for creating a revision of the current post state.

The official wp_save_post_revision() documentation explains that a revision is typically created around a post update.

WordPress does not necessarily create an identical revision every time

Current Core logic compares revision-supported fields with the latest stored normal revision.

By default, a new revision is saved when relevant revisioned content has changed.

This helps avoid retaining pointless duplicate versions when there is no meaningful difference in the fields WordPress revisions.

Which fields are revisioned by default?

The standard revision architecture tracks core content fields including:

• title;
• author;
• content;
• excerpt.

WordPress internally determines revision-supported fields through its revision API.

Post metadata can also support revisions

Modern WordPress versions allow registered post metadata to opt into revision support.

The official register_meta() documentation includes:

revisions_enabled

for metadata registered against revision-supporting post types.

For example:

register_post_meta(
    'post',
    '_project_subtitle',
    array(
        'single'            => true,
        'type'              => 'string',
        'show_in_rest'      => true,
        'revisions_enabled' => true,
    )
);

Not every post meta value is automatically revisioned

This matters when building custom editing experiences.

Do not assume:

post has revisions
↓
every wp_postmeta value
automatically has historical versions

Revision support for custom metadata needs to be designed deliberately.

Custom post types must support revisions

A custom post type can declare:

'supports' => array(
    'title',
    'editor',
    'revisions'
)

when registered.

If the post type does not support:

revisions

WordPress revision APIs will not treat it like a revision-enabled content type.

The official post_type_supports() documentation covers feature support checks.

Check whether revisions are enabled for a post

WordPress provides:

wp_revisions_enabled()

which evaluates whether revision support is active for a particular post.

This accounts for:

• post-type support;
• revision configuration;
• WordPress revision policy.

Per-post-type revision limits are possible

You do not necessarily need one revision-retention value for every post type.

WordPress provides:

wp_revisions_to_keep

and a post-type-specific revision-retention filter.

The official wp_revisions_to_keep documentation allows developers to modify the number of revisions retained for a particular post.

Example: keep fewer revisions for one post type

add_filter(
    'wp_revisions_to_keep',
    function (
        $num,
        $post
    ) {

        if (
            'product_note'
            === $post->post_type
        ) {
            return 5;
        }

        return $num;
    },
    10,
    2
);

This can be useful when different content types have very different editorial requirements.

One global revision limit is not always ideal

Consider:

Blog articles
→ edited frequently
→ 20 revisions useful

Legal notices
→ rarely changed
→ 5 revisions enough

Landing pages
→ page builder
→ larger revisions
→ 10 revisions enough

A thoughtful retention policy can reflect actual content workflows.

TheOneWP Post Revisions provides a dedicated revision-retention control for WordPress content.

Autosave is primarily about recovery

Suppose an editor writes:

1,500 words

but has not yet clicked:

Save draft
or
Update

If the browser closes unexpectedly, the most useful data may not be the last normal revision.

It may be the newer autosaved copy created during the interrupted editing session.

Revisions are primarily about history

Now suppose the article was deliberately updated several times:

Monday
→ first draft

Tuesday
→ editorial rewrite

Wednesday
→ legal correction

Thursday
→ published version

Normal revisions provide the historical trail that allows earlier versions to be inspected and restored.

A practical example

Imagine a published page contains:

Version 1
"Free shipping over $50."

An editor changes it and deliberately saves:

Version 2
"Free shipping over $75."

WordPress can retain Version 1 as a historical revision.

The editor then starts changing the sentence to:

"Free shipping for premium members."

but has not saved yet.

An autosave may contain that unfinished Version 3.

The structure becomes:

Revision
→ Version 1

Current published content
→ Version 2

Autosave
→ unfinished Version 3

How does autosave recovery work?

When WordPress detects autosaved content newer than the version currently being edited, it can notify the editor that recoverable content exists.

The user can then inspect or restore the autosaved state rather than reconstructing lost work manually.

Autosave is not a website backup

An autosave protects a particular editing state.

It does not protect:

• the complete database;
• theme files;
• plugin files;
• uploads;
• server configuration;
• all website settings.

A complete backup belongs to a different recovery layer.

TheOneWP Backup Manager provides a separate backup system for broader recovery requirements.

A revision is not a complete backup either

A revision represents an earlier state of supported content fields.

It does not represent a snapshot of the entire WordPress installation.

The hierarchy is:

Autosave
→ editing-session recovery

Revision
→ content-history recovery

Backup
→ site or database recovery

How do you view WordPress revisions?

For content with available revisions, WordPress exposes revision history through the editor’s document settings.

In current WordPress versions, the sidebar displays the number of available revisions when revision history exists.

Opening it launches the revisions interface.

WordPress 7.0 introduced a redesigned revisions screen

WordPress 7.0 introduced a newer revision experience.

The current WordPress revisions documentation explains that the newer interface includes a top timeline-style slider and visual change indicators.

The revision interface highlights different kinds of changes

Current WordPress documentation identifies:

Green
→ inserted content

Red
→ deleted content

Yellow
→ changed content

This makes it easier to move through revision history and identify which parts of the content changed.

The classic revision screen remains available

WordPress 6.9 and earlier use the classic revisions interface by default.

WordPress 7.0 also retains access to the classic screen.

The classic interface supports:

• side-by-side comparison;
• next and previous navigation;
• comparison between selected revisions;
• restoration of a historical version.

How does restoring a revision work?

WordPress provides:

wp_restore_post_revision()

for restoring revision data to its parent post.

The official wp_restore_post_revision() documentation allows WordPress to restore all revision-supported fields or a selected subset.

Restoring a revision does not mean deleting later history

Conceptually, restoration means:

select historical version
↓
copy its revisioned fields
back into current post
↓
current post becomes based
on that earlier version

WordPress’s revision workflow is designed so restoration itself remains part of an editable history rather than acting like destructive time travel.

Do not edit revision rows manually

A revision belongs to WordPress’s content architecture.

Use:

• the WordPress editor;
• WordPress revision APIs;
• documented maintenance tools;

rather than manually rewriting revision rows through arbitrary SQL.

wp_get_post_revisions() retrieves revision history

Developers can retrieve revisions through:

wp_get_post_revisions()

The official wp_get_post_revisions() reference provides the programmatic interface for retrieving revisions associated with a post.

For example:

$revisions =
    wp_get_post_revisions(
        $post_id
    );

Do not use direct SQL when WordPress already provides revision APIs

This:

SELECT *
FROM wp_posts
WHERE post_type = 'revision';

may be useful during investigation.

It is usually not the best basis for application behavior when WordPress already provides APIs that understand the revision model.

Autosave and Heartbeat are related but not identical

The WordPress Heartbeat API provides recurring communication between the administration interface and the server.

Heartbeat supports functionality related to editing workflows, including:

• post locking;
• session coordination;
• plugin background communication.

See The WordPress Heartbeat API, Explained.

Do not treat Heartbeat frequency as the autosave interval

These are separate concepts.

Heartbeat interval
→ periodic admin communication

AUTOSAVE_INTERVAL
→ autosave timing

Revision retention
→ historical versions kept

Changing one does not automatically configure the others.

Autosave and post locking are different systems

Post locking asks:

Who is currently editing
this content?

Autosave asks:

What unsaved work should
be recoverable?

Revisions ask:

What did the saved content
look like previously?

See WordPress Post Locking Explained for the concurrent-editing side of the workflow.

Why WordPress keeps these systems separate

Consider two editors.

Alice
→ currently editing post 100

Bob
→ opens post 100

Post locking helps prevent accidental concurrent editing conflicts.

Alice’s autosave helps recover her current work.

Normal revisions preserve the historical versions already committed through previous saves.

Each layer solves a different problem.

Does autosave increase database writes?

Autosave activity can generate database writes because editing state needs to be persisted.

However, it is misleading to assume:

one autosave interval
=
one permanently accumulating row

because the autosave for a given user and post is reused rather than creating an unlimited sequence.

Should you increase the autosave interval to reduce database writes?

Possibly, but only after considering the editorial tradeoff.

A longer interval can reduce autosave frequency.

It also increases the amount of recent work that may not yet have a server-side autosave when an editing session fails.

For example:

60-second interval

maximum theoretical gap
between autosave opportunities:
approximately 1 minute

versus:

600-second interval

maximum theoretical gap:
approximately 10 minutes

The exact real-world behavior also depends on editor activity, connectivity and the editing implementation.

Do not optimize autosave merely because it writes to the database

Autosave exists to prevent content loss.

On a publishing team producing long articles, removing a small amount of database activity may be a poor trade if it significantly increases lost work.

See How to Reduce Database Writes in WordPress for a broader optimization strategy.

Revision retention affects database growth more directly

Unlike autosaves, normal revisions can accumulate as content is edited over time.

Consider:

5,000 posts
×
30 retained revisions
=
up to 150,000
historical revision records

The real storage impact depends on:

• content length;
• number of revision-enabled posts;
• editing frequency;
• revisioned metadata;
• page-builder data;
• database configuration.

Large page-builder revisions can matter

A simple article revision may contain relatively modest content.

A page-builder revision can preserve a much larger serialized or structured document state depending on the builder and integration.

Therefore:

10 revisions
of a short post

and:

10 revisions
of a complex landing page

may have very different storage costs.

Do revisions slow down WordPress?

The answer depends on the workload.

Simply having revisions does not mean every frontend request becomes slow.

Most normal frontend queries are interested in:

published content

rather than loading every historical revision.

However, very large revision volumes can contribute to:

• larger database tables;
• larger backups;
• slower migrations;
• heavier revision-management queries;
• larger development copies;
• more storage consumption.

See WordPress Database Bloat, Explained for the wider storage issue.

Database size alone is not a performance metric

A large database containing useful content is not automatically unhealthy.

A small database with poor query patterns can still perform badly.

See Optimizing the WordPress Posts Table for the distinction between table size and query performance.

Should you disable revisions?

Usually, disabling revisions entirely should be a deliberate workflow decision rather than a generic performance recommendation.

Revisions provide:

• editorial recovery;
• historical comparison;
• protection against accidental changes;
• a way to restore previous content;
• useful audit context.

For many sites, a limited retention policy is more balanced than complete removal.

Example: keep ten revisions

define(
    'WP_POST_REVISIONS',
    10
);

This keeps historical recovery available while preventing indefinite accumulation of ordinary revisions.

How many revisions should you keep?

There is no universal correct number.

Consider:

• how frequently content changes;
• how many editors work on the site;
• how valuable historical recovery is;
• how large each revision tends to be;
• how long editorial approval cycles last;
• how large the database already is;
• backup and migration requirements.

Small company website

A site with infrequently edited pages may be comfortable with:

5–10 revisions

per item.

Editorial publication

A news or publishing team may benefit from:

20
30
or more

depending on workflow and recovery requirements.

Highly regulated or audited content

Some environments may have reasons to preserve much longer history.

In that case, storage reduction may be less important than traceability.

WordPress revisions alone should not automatically be treated as a complete regulatory audit system, however.

Revision limits clean old revisions during future revision processing

A revision limit controls the number WordPress intends to retain as revisions continue to be created.

Do not assume that merely defining:

WP_POST_REVISIONS = 10

will instantly scan the complete database and remove every historical revision beyond ten from every post.

Existing cleanup should be considered separately.

Changing future policy and cleaning old data are separate operations

Revision configuration
→ controls future retention behavior

Database cleanup
→ removes already accumulated data

TheOneWP Post Revisions addresses revision policy.

TheOneWP Database Optimizer addresses supported database-cleanup categories.

Back up before deleting large revision histories

Historical revisions exist specifically to make recovery possible.

Mass-deleting them without a recovery point defeats that purpose fairly efficiently.

Create a backup before large cleanup operations.

TheOneWP Backup Manager provides a separate recovery layer for database and broader backup workflows.

Use Database Manager for inspection

TheOneWP Database Manager can help inspect the underlying tables and stored records when revision growth requires deeper investigation.

The appropriate sequence is:

measure
↓
identify revision volume
↓
decide retention requirement
↓
back up
↓
clean if appropriate
↓
measure again

Do not delete every revision just because there are many

A revision is not automatically database waste.

Ask:

• Is this history useful?
• How far back do editors realistically restore?
• How much storage does it consume?
• Does the site have an external editorial history system?
• Would losing it create operational risk?

Do not confuse revisions with database bloat automatically

Database bloat means unnecessary or disproportionately retained data.

Useful revision history is legitimate data.

The same set of revisions can therefore be:

useful history
on one site

and

unnecessary excess
on another

Autosaves normally do not create the same long-term growth pattern

Because WordPress keeps a maximum of one autosave per user for a particular post, autosaves do not normally accumulate like unlimited normal revisions.

If the database has an enormous revision count, investigate:

normal revisions
before assuming
autosave is responsible

Autosave and browser-local recovery are not necessarily identical

Modern editing interfaces can have additional client-side protection mechanisms.

A browser-local recovery mechanism and WordPress’s server-side autosave system should not automatically be treated as the same layer.

The important distinction remains:

client-side temporary state
→ browser environment

WordPress autosave
→ server-side WordPress state

Do not rely exclusively on browser-local recovery

Local browser storage can disappear because of:

• browser cleanup;
• private browsing;
• device failure;
• switching devices;
• storage restrictions.

Server-side autosave provides a different recovery mechanism.

Autosave and manual Save Draft are different

Clicking:

Save draft

commits the draft through the normal WordPress post-saving workflow.

Autosave exists so progress can be protected without requiring the user to manually trigger that save.

Autosave and Update are different too

For published content:

Update
→ deliberately changes
the current post

Autosave
→ preserves work
without publishing it

This separation protects the live page from unfinished editorial changes.

Autosave and preview can interact

When an editor previews content that has not yet been committed to the main post state, WordPress can use autosaved data to generate the preview representation.

The revision architecture therefore supports both recovery and preview-related editing workflows.

Developers should exclude autosaves from unrelated save_post logic

A common custom-plugin pattern is:

add_action(
    'save_post',
    'project_save_data'
);

If the callback should only run for intentional post saves, it may need to recognize autosave activity.

Use wp_is_post_autosave()

For example:

function project_save_data(
    $post_id
) {

    if (
        wp_is_post_autosave(
            $post_id
        )
    ) {
        return;
    }

    if (
        wp_is_post_revision(
            $post_id
        )
    ) {
        return;
    }

    // Normal save logic.
}

This prevents unrelated metadata or integrations from being executed merely because WordPress created an autosave or revision.

DOING_AUTOSAVE is also commonly encountered

Some WordPress save callbacks check:

defined(
    'DOING_AUTOSAVE'
)
&&
DOING_AUTOSAVE

However, developers should understand the exact context they are trying to exclude rather than copying defensive conditions blindly.

Functions such as:

wp_is_post_autosave()
wp_is_post_revision()

communicate the actual record type clearly.

Autosave can trigger expensive plugin behavior accidentally

Suppose a plugin performs:

save post
↓
send remote API request
↓
regenerate report
↓
clear site cache
↓
write audit record

on every relevant save hook.

If autosave traffic triggers all of those operations unnecessarily, the editing experience and server load can suffer.

Audit custom save callbacks

Ask:

• Should this run on autosave?
• Should this run when a revision is created?
• Should it run only when the main post is deliberately updated?
• Does it repeat expensive remote work?
• Does it write additional metadata unnecessarily?

This is another connection to How to Reduce Database Writes in WordPress.

Custom revision metadata needs deliberate registration

If an important custom field must travel through historical versions, configure it for revision support.

If the metadata represents:

runtime cache
analytics count
last viewed timestamp
temporary processing state

revisioning it usually makes little sense.

Separate editorial state from runtime state

Good revision candidates include:

• subtitle;
• editorial summary;
• structured page content;
• revision-worthy design settings.

Poor candidates often include:

• view count;
• last cache rebuild;
• background queue position;
• temporary lock;
• API synchronization timestamp.

Revisions should represent recoverable content state

A useful test is:

If I restore an old revision,
should this value also become
what it was at that time?

If the answer is yes, the metadata may belong in the revision model.

If the answer is no, it probably should not.

Page builders may implement additional revision behavior

WordPress provides the Core revision system, but page builders and complex editing tools may store additional content or metadata.

Some integrate closely with Core revisions.

Others may provide additional history systems.

Do not assume that:

WordPress revision limit
=
complete history policy
for every page builder

Check the builder’s own architecture.

WooCommerce and plugin content types may behave differently

Custom post types can enable or disable revision support independently.

Do not assume every object stored in:

wp_posts

automatically maintains normal post revision history.

Check:

post_type_supports(
    $post_type,
    'revisions'
)

Autosaves also depend on the editing architecture

Standard WordPress posts and pages have autosave support.

Custom editing systems can implement additional behaviors or bypass parts of the normal editor flow.

Test the actual content type rather than assuming every custom admin screen behaves like the standard post editor.

Autosave does not replace collaboration controls

If two users edit the same post simultaneously, two autosaves do not automatically merge the users’ intentions.

Post locking and editorial coordination remain important.

See WordPress Post Locking Explained.

Autosave is not version control

Autosave is designed for:

recovery

not:

complete historical change management

Normal revisions provide more of that historical role.

Even revisions are not a replacement for source-control systems when managing code, configuration or deployment artifacts.

Revision history can improve editorial confidence

An editor can make substantial changes knowing that earlier saved versions may remain recoverable.

This can encourage safer:

• rewrites;
• SEO updates;
• legal corrections;
• content refreshes;
• collaborative review.

Autosave improves editing resilience

Autosave protects against a different class of failure:

• unexpected browser closure;
• connection interruption;
• device problems;
• accidental navigation;
• editing-session interruption.

These benefits should be considered before aggressively increasing the autosave interval.

When should you increase the autosave interval?

Possible reasons include:

• a highly constrained hosting environment;
• many simultaneous editors;
• measured autosave-related server pressure;
• custom admin workflows where frequent recovery points provide little value.

Change the interval only after measuring the actual workload.

When should you decrease the autosave interval?

A shorter interval may be appropriate when:

• editors write long-form content;
• network interruptions are common;
• losing several minutes of work would be expensive;
• server capacity comfortably supports the workload.

A shorter interval means more frequent recovery opportunities.

Do not choose the autosave interval based only on database size

Autosaves do not accumulate like normal revisions.

Therefore an enormous revisions table is not automatically evidence that:

AUTOSAVE_INTERVAL
is too small

Measure the actual source of the records first.

When should you limit revisions?

Revision limits become worth reviewing when:

• the site contains many frequently edited posts;
• page-builder revisions are large;
• database backups are becoming heavy;
• migrations take excessive time;
• very old revisions provide little recovery value;
• database storage is constrained.

Do not choose a revision limit only from a performance tutorial

The appropriate number depends on workflow.

A site where content is edited once and never touched again has different requirements from an editorial operation with twenty writers.

Review revision policy as the site grows

A configuration that was irrelevant with:

30 posts

may become meaningful with:

30,000 posts

especially when each post has a long editing history.

Revision cleanup and future retention are different

After choosing a new limit, you may still need to review historical data already stored.

The safe workflow is:

measure existing revisions
↓
choose future retention
↓
create backup
↓
clean known excess
↓
verify site
↓
measure again

Use staging before aggressive revision changes

Test significant changes away from production when possible.

Especially test:

• custom post types;
• page builders;
• revisioned metadata;
• custom editor plugins;
• restoration workflows.

See WordPress Staging Site Best Practices.

Test autosave recovery

A useful controlled test is:

1. Open a draft.

2. Make an identifiable change.

3. Wait beyond the autosave interval.

4. Verify autosave activity.

5. Simulate leaving without
   committing the change.

6. Return to the post.

7. Confirm WordPress exposes
   the recoverable version.

Test normal revisions separately

Then:

1. Save Version A.

2. Change the content.

3. Save Version B.

4. Change the content again.

5. Save Version C.

6. Open Revisions.

7. Verify A, B and C
   can be compared as expected.

Test restoration before relying on it operationally

Select an earlier controlled test revision and restore it.

Confirm:

• the expected title returns;
• the expected content returns;
• revision-enabled metadata behaves correctly;
• page-builder content remains coherent;
• the frontend renders correctly.

Test custom fields

If the site depends on custom post metadata, explicitly verify whether those values are included in revision history.

Never assume every custom field is versioned merely because the editor shows a revision count.

Test multiple users

For collaborative sites:

User A
→ edits post

User B
→ edits same post

verify:

• post locking;
• autosave behavior;
• revision attribution;
• recovery behavior.

Check attribution in revision history

Revision records help indicate which editor was associated with a saved historical version.

This can be useful for editorial review, although revisions should not automatically be treated as a complete immutable audit log.

Revisions are editable application data

Administrators, plugins and database maintenance processes can modify or delete revision data.

If an organization requires tamper-resistant compliance logging, use an architecture specifically designed for that requirement.

Autosaves are even more temporary by nature

An autosave should be thought of as:

working recovery state

rather than permanent history.

A newer autosave replaces the user’s earlier autosave for that post.

Common mistake: treating autosave and revisions as synonyms

Autosaves use revision infrastructure, but their operational purposes differ.

Use:

autosave
→ temporary editing recovery

revision
→ historical saved version

Common mistake: thinking WordPress creates a new autosave row every minute forever

WordPress normally keeps one autosave per user per post.

Newer autosaves replace earlier autosave state.

Common mistake: changing AUTOSAVE_INTERVAL to control revision history

Autosave frequency and revision retention are independent.

Common mistake: changing WP_POST_REVISIONS to control autosave frequency

The revision limit does not define how frequently WordPress protects current editing work.

Common mistake: disabling revisions and assuming autosave disappears

WordPress preserves autosave as a separate recovery mechanism.

Common mistake: disabling autosave because the database contains many revisions

Large historical revision counts normally require investigation of revision retention rather than an assumption that autosave generated every row.

Common mistake: deleting all revisions as a generic optimization

Revision history has operational value.

Choose a retention policy based on real recovery requirements.

Common mistake: assuming revision limits instantly delete all historical excess

Future retention policy and cleanup of already accumulated records are separate concerns.

Common mistake: treating revisions as full backups

A revision contains supported content state, not the entire WordPress installation.

Common mistake: treating autosave as a full backup

Autosave protects editing progress for a specific content item.

Common mistake: assuming all post meta is revisioned

Custom metadata needs appropriate revision support.

Common mistake: assuming every custom post type supports revisions

Revision support must be registered for the post type.

Common mistake: triggering expensive plugin code during autosave

Audit custom save hooks and exclude autosave or revision records when that processing is unnecessary.

Common mistake: globally disabling Heartbeat to change autosave behavior

Heartbeat, post locking, autosave and revision retention are related editing systems but separate mechanisms.

Changing one without testing the others can create unexpected editor problems.

Common mistake: setting the autosave interval extremely high

A value such as:

3600 seconds

means a potential one-hour interval between autosave opportunities.

That may defeat much of the recovery benefit.

Common mistake: using unlimited revisions without ever reviewing the policy

Unlimited history can be appropriate.

It should still be intentional.

Common mistake: applying one revision limit to every workflow automatically

Different post types can have different historical requirements.

Common mistake: performing direct SQL cleanup without a backup

Revision deletion is destructive.

Create a recoverable backup first.

Common mistake: assuming a large database means revisions are responsible

A WordPress database can also grow because of:

• post meta;
• orders;
• logs;
• transients;
• comments;
• custom plugin tables;
• analytics;
• queue data.

Inspect before deleting.

How TheOneWP separates autosave and revision controls

TheOneWP treats autosave timing and revision retention as separate responsibilities because WordPress itself treats them as separate systems.

Autosave Interval

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

Its purpose is:

editing recovery timing

Post Revisions

TheOneWP Post Revisions controls how many historical content revisions WordPress retains.

Its purpose is:

revision-history retention

Database Optimizer

TheOneWP Database Optimizer addresses supported historical cleanup categories after unnecessary database data has already accumulated.

Database Manager

TheOneWP Database Manager provides direct inspection of WordPress tables and stored records when deeper database investigation is required.

Backup Manager

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

Keep these controls conceptually separate

Autosave Interval
→ How often should WordPress
protect unsaved editing work?

Post Revisions
→ How much saved content
history should WordPress retain?

Database Optimizer
→ Which known disposable
historical records can be cleaned?

Database Manager
→ What is actually stored
in the database?

Backup Manager
→ How can the database
or site be recovered?

Recommended decision process

When reviewing autosaves and revisions, use this order:

Understand editing workflow
↓
measure revision volume
↓
review autosave requirements
↓
choose autosave interval
↓
choose revision retention
↓
test custom fields
↓
test custom post types
↓
create backup
↓
clean historical excess
if appropriate
↓
measure again

Autosave checklist

• Understand that autosave protects unsaved editing work.
• Remember that the default interval is 60 seconds.
• Remember that autosave frequency and revision retention are separate.
• Expect a maximum of one autosave per user per post.
• Do not assume one permanent row is added every autosave interval.
• Do not assume disabling normal revisions disables autosave.
• Test autosave recovery before changing production behavior.
• Consider editorial workflow before increasing the interval.
• Use a shorter interval when frequent recovery points are operationally valuable.
• Use a longer interval only when the tradeoff is understood.
• Test custom editors and page builders separately.
• Test multiple-user editing environments.
• Do not run expensive custom save logic unnecessarily during autosave.
• Use wp_is_post_autosave() where custom save callbacks need to exclude autosaves.
• Do not treat autosave as a complete website backup.

Post revision checklist

• Understand that revisions preserve historical saved versions.
• Remember that normal revisions are unlimited by default.
• Use WP_POST_REVISIONS when a global retention limit is appropriate.
• Use revision filters when different content types need different limits.
• Confirm that custom post types support revisions.
• Check whether important custom metadata has revision support.
• Do not assume every post meta value is revisioned automatically.
• Review page-builder revision size.
• Measure database storage before deleting history.
• Keep enough revisions for realistic recovery.
• Do not disable revisions solely because they use database space.
• Do not assume a revision limit immediately cleans the historical database.
• Create a backup before large revision deletion.
• Use WordPress-aware cleanup when possible.
• Test revision restoration before depending on it operationally.
• Review revision policy again as the site grows.

Related guides

• What Are WordPress Post Revisions, Really?
• How WordPress Post Revisions Work
• How to Change the WordPress Autosave Interval
• WordPress Post Locking Explained
• The WordPress Heartbeat API, Explained
• WordPress Database Bloat, Explained

Final recommendation

The easiest way to understand WordPress autosave and post revisions is to stop treating them as two names for the same feature.

They belong to the same broader revision architecture, but they exist for different reasons.

Autosave
→ protects work
that has not yet been
deliberately saved

Revision
→ preserves content
that was saved previously

The default WordPress autosave interval is 60 seconds, but WordPress does not permanently add another autosave row every minute. It normally keeps a maximum of one autosave per user for a given post and replaces that user’s earlier autosave as editing continues.

Normal revisions follow a different retention policy. For revision-enabled content, WordPress keeps an unlimited number by default unless WP_POST_REVISIONS or revision filters establish a limit.

That means the correct controls are:

Need more or fewer
recovery checkpoints?
→ adjust autosave interval

Need more or less
historical content?
→ adjust revision retention

Database already contains
too much old revision data?
→ review and clean existing data

Need complete site recovery?
→ use backups

Do not increase the autosave interval merely because the database contains many revisions. Do not disable revisions merely because autosave exists. Do not disable Heartbeat assuming it is simply another name for autosave. And do not delete historical revisions before deciding how much editorial recovery your site genuinely needs.

The safer workflow is:

preserve useful editor recovery
+
retain useful content history
+
limit unnecessary historical growth
+
back up before destructive cleanup

TheOneWP Autosave Interval manages editing-recovery frequency, while Post Revisions manages historical retention.

Database Manager and Database Optimizer address inspection and supported cleanup separately, and Backup Manager provides a recovery point before destructive maintenance.

Once autosave timing, revision retention and database cleanup are treated as separate decisions, WordPress’s content-history system becomes considerably easier to configure correctly.