WordPress saves every draft change you make as a post revision. Every autosave, every manual save, every time you click update. Those revisions live forever in the wp_posts table unless you explicitly limit or purge them.
For a solo operator publishing twice a week, this rarely matters. For a site with daily posts, guest contributors, or heavy editing cycles, you can end up with tens of thousands of revision rows that slow down queries, inflate backups, and make database migrations painfully slow.
Here’s when revisions become a problem, how to cap them, and what happens when you purge old ones.
How revisions accumulate faster than you think
WordPress creates a new revision on every save—manual or automatic. The default autosave interval is 60 seconds. If you spend 20 minutes editing a post and save manually three times, you’ve just created roughly 23 revisions for a single post.
Multiply that across a year of publishing, especially if you have multiple authors or use tools that auto-update posts (like content refreshers or dynamic blocks), and you’re looking at 5,000–15,000 revision rows per year for a modest site.
Each revision is a full duplicate of the post content at that moment—title, body, meta. It’s not a diff. That’s why a site with 500 published posts can have 8,000 rows in wp_posts.
When revisions start causing real problems
Revisions don’t directly slow down your front end—visitors never query them. But they do three things that hurt:
- Admin dashboard queries slow down. The post editor loads all revisions for the current post. If a single post has 200 revisions, that’s a noticeable lag when you open it.
- Backup file sizes balloon. Your nightly database backup includes every revision. A 50 MB database becomes 200 MB, which slows down both the backup process and restores.
- Database exports and migrations take longer. If you’re moving hosts or cloning a site, you’re waiting for thousands of unnecessary rows to export and import.
You’ll notice the impact most clearly when running a plugin like WP-Optimize or querying the database directly. A SELECT that should return 500 posts instead scans 8,000 rows because revisions share the same table.
How to cap revisions going forward
Add this line to your wp-config.php file, anywhere above the line that says /* That's all, stop editing! */:
define( 'WP_POST_REVISIONS', 5 );
This limits WordPress to keeping the five most recent revisions per post. Older revisions are automatically deleted when a new one is created.
Five is a sensible default for most solo operators. It’s enough to undo a bad edit or recover from an accidental overwrite, but not so many that you’re hoarding years of draft history you’ll never look at.
If you want to disable revisions entirely, set it to false:
define( 'WP_POST_REVISIONS', false );
This stops all future revisions. Autosave still works—you can still recover unsaved changes—but WordPress won’t store a permanent history.
How to purge existing revisions
Capping revisions only affects new saves. It doesn’t touch the thousands of old revisions already sitting in your database.
To remove those, you have two options: a plugin or a direct SQL query.
Plugin method: Install WP-Optimize (free) or WP Sweep (free). Both have a one-click option to delete all post revisions. WP-Optimize also lets you schedule automatic cleanups weekly or monthly.
SQL method: If you’re comfortable with database access, run this query in phpMyAdmin or your host’s database tool:
DELETE FROM wp_posts WHERE post_type = 'revision';
This deletes every revision from your database immediately. Make sure you have a backup first—this is irreversible.
After running the query, also run OPTIMIZE TABLE wp_posts; to reclaim the disk space and rebuild the table index. Without this step, your database file size won’t actually shrink.
The tradeoff: losing granular undo history
Capping or purging revisions means you can’t travel back to a draft from six months ago. For most operators, that’s fine—you’re not auditing edit history or rolling back to ancient versions.
But if you’re running a site with compliance requirements, guest contributors who might dispute changes, or content that frequently gets reverted (like policy pages or legal disclaimers), keep more revisions or use a version-control plugin like Revisionary or WP Document Revisions instead.
For everyone else, five revisions and an annual purge is a reasonable maintenance habit that keeps your database lean without sacrificing practical undo capabilities.
If you’re dealing with WordPress performance issues beyond revisions—caching, plugin conflicts, or database optimisation—reply and let me know what’s slowing you down. I’ll cover it in a future piece.