Years of editing can leave thousands of revisions in a WordPress database. Deleting them all may save space, but it can also remove the versions editors and legal teams rely on during recovery or review.
Measure revision volume by post type and age, agree on a retention rule and clean a small batch before applying it broadly.
What it means
A revision is a stored historical version of a supported post type. Autosaves are related working copies that protect current editing sessions; neither should be confused with the published post itself.
Revision cleanup removes selected historical records and associated metadata. It should preserve the current post and whatever recent history the editorial policy requires.
A realistic WordPress example
A publication has six years of revisions, but its newsroom needs the previous 90 days for comparisons and occasional restoration. The database is large, yet nobody has shown how much space those revisions use.
The team counts them by age and post type, retains the agreed window and deletes an older sample. Editors then compare versions, restore a recent revision and test autosave before the remaining batches proceed.
Why it matters and when to use it
A defined policy keeps useful recovery points while limiting unbounded historical data. Cleanup is worthwhile when measured revision volume is material and the retained history still meets editorial and compliance needs.
Do not run it during a migration, an active publishing event or any period when the required retention cannot be stated clearly.
A straightforward route for beginners
- Back up the database and confirm that the backup can be restored.
- Count revisions by age and post type instead of assuming they dominate database size.
- Ask editorial and compliance owners how much history must remain.
- Select a small set older than that retention threshold.
- Delete only that approved set, then reopen revision history and restore one recent version.
- Recount the rows and continue in manageable batches only if publishing and autosave still work.
The advanced route
Separate revisions, autosaves, current posts and their metadata in the audit. Custom post types may have different operational or legal value, so a single age threshold is not always appropriate.
For large tables, use bounded batches during a quiet window and observe locks, runtime and replication lag where relevant. Size reclamation may require separate database work and is not proof that the logical cleanup succeeded.
Risks, common mistakes, backup, and rollback
Unscoped deletion can remove the only convenient recovery point for a recent edit. A query that misidentifies current rows or skips related metadata can also damage content or leave waste behind.
Keep the verified database backup until editors have tested comparison, preview, autosave, scheduled publishing and restoration. Stop at the first missing version or behavioral regression.
How AIOWS helps:
AIOWS Database Cleaner
AIOWS Database Cleaner provides a visible WordPress maintenance path for supported cleanup categories such as old revisions. Use the revision scope deliberately rather than combining it with unrelated database deletions.
Start from a fresh backup, record the retention threshold and measure the target before running the cleanup. Afterwards, recount revisions and test the editorial functions that depend on them.
The module cannot decide how much history a newsroom or regulated site must keep. That policy belongs to the content owners, and an independent database restore remains the recovery path if required versions are removed.
Related AIOWS articles
- How to Delete Expired Transients in WordPress
- How to Remove Spam and Trashed Comments from WordPress
- How to Optimize WordPress Database Tables Safely
Conclusion and recommended route
Keep current content and the history your editors need, then remove only revisions beyond an approved retention rule. A small verified batch is more valuable than a large unexplained reduction in database size.
