WordPress stores every draft change you make as a separate database row. Hit “Save Draft” twenty times while writing a post? That’s twenty revision rows in wp_posts. Multiply that across hundreds of articles, and you’re storing thousands of rows you’ll never open again.
Most operators don’t notice until their database export takes five minutes instead of thirty seconds, or their backup plugin starts timing out. By then, revisions often account for 40–60% of total database size.
The revision math
WordPress defaults to unlimited revisions. A typical blog post might generate 15–25 revisions during drafting and editing. If you publish 100 posts per year, that’s 1,500–2,500 revision rows annually—on top of the 100 published post rows you actually need.
After three years, a site with 300 published posts might carry 4,500–7,500 revision rows. Each revision duplicates the post content, metadata, and timestamps. A 2,000-word post stored as HTML averages 12–15 KB per revision. Twenty revisions = 240–300 KB of database space for a single article’s edit history.
Database bloat compounds during backups. Tools like UpdraftPlus or BackupBuddy export the entire wp_posts table. A 300-post site with unlimited revisions can generate 80–120 MB backup files when the live content itself occupies 15–20 MB.
Setting a sane limit
Add this line to wp-config.php, above the “stop editing” comment:
define('WP_POST_REVISIONS', 5);
Five revisions cover most real-world recovery scenarios. You can roll back a paragraph you deleted an hour ago, compare yesterday’s draft to today’s, or retrieve content after an accidental bulk delete. You won’t need the version from three weeks ago.
Setting the limit doesn’t delete existing revisions—it only caps future saves. To purge old revisions, install WP-Optimize (free) or run this SQL query directly in phpMyAdmin:
DELETE FROM wp_posts WHERE post_type = 'revision';
Test on staging first. The query is irreversible.
When to keep more revisions
Multi-author sites benefit from higher limits—10 to 15 revisions—especially when editors frequently revert contributor drafts or compare versions across handoffs. Content sites that publish long-form investigative pieces or data-heavy articles might want a week’s worth of recovery options.
But solo operators publishing 2–4 posts per week rarely need more than five. The trade-off between database bloat and recovery flexibility tips heavily toward limiting revisions once you pass 200 published posts.
Autosave vs. revisions
WordPress autosaves every 60 seconds by default, separate from manual revisions. Each autosave overwrites the previous one—it doesn’t create a new row. Autosaves don’t contribute to bloat, but they do create a recovery point independent of your revision limit.
If you want to extend the autosave interval to reduce database writes (useful on high-traffic shared hosting), add this to wp-config.php:
define('AUTOSAVE_INTERVAL', 300);
That sets autosave to five minutes. Solo operators can safely push this to 180–300 seconds without meaningful risk.
Monitoring revision bloat
Run this query in phpMyAdmin to count total revisions:
SELECT COUNT(*) FROM wp_posts WHERE post_type = 'revision';
Compare that number to your published post count. If revisions outnumber posts by more than 10:1, you’re carrying dead weight. Purge old revisions, set a limit, and check again in three months.
Database optimization plugins like WP-Optimize show revision counts in their dashboards and let you schedule monthly cleanups. Set it to keep the five most recent revisions per post and auto-delete the rest. After the first purge, most solo sites drop 30–50% in database size.
Want more WordPress infrastructure breakdowns like this? Reply and tell me which hosting mystery to unpack next—I read every response.