WordPress saves a complete copy of your post content every time you hit save. Not a delta. Not a diff. The entire post body, custom fields, and metadata—duplicated in full and written to wp_posts with a row type of revision.
For a solo operator publishing three posts a week, this rarely matters. But if you’re running a content site with multiple contributors, long-form articles, or dozens of custom fields per post, revision storage can balloon into hundreds of megabytes—sometimes gigabytes—of database bloat that slows queries, inflates backups, and complicates migrations.
Where revisions live and how they grow
WordPress stores every revision as a separate row in the wp_posts table, linked to the parent post by post_parent. Each revision carries the full post_content, post_title, post_excerpt, and timestamp. If you use custom fields or a page builder that serializes layout data into post meta, those get duplicated too—in wp_postmeta, keyed to the revision ID.
By default, WordPress keeps every revision forever. A 5,000-word post edited twenty times generates twenty full copies of that content. If you’re embedding base64 images in custom fields or storing JSON layout blocks, each revision can exceed 100 KB. Twenty revisions × 100 KB = 2 MB for one post.
Multiply that across a year of publishing and you’re looking at meaningful disk usage—and slower SELECT queries whenever WordPress scans wp_posts without an index filter on post_type.
How to cap or disable revisions
You can limit the number of revisions WordPress keeps by adding a constant to wp-config.php:
define( 'WP_POST_REVISIONS', 5 );
This keeps the five most recent revisions per post and discards older ones on the next save. Setting it to false disables revisions entirely, though that also removes the ability to roll back accidental edits—useful for solo operators who publish fast and rarely need an undo buffer.
To disable autosave (which triggers a revision every 60 seconds by default), add:
define( 'AUTOSAVE_INTERVAL', 300 );
That pushes the interval to five minutes. You can’t disable autosave completely without a plugin, but stretching the interval cuts down on duplicate saves during editing sessions.
The WordPress Codex documents both constants under Revisions (checked November 2026).
When to prune and how much you’ll recover
If you’ve been running WordPress for years without a revision limit, you can reclaim disk space by deleting old revisions. Plugins like WP-Optimize and Advanced Database Cleaner offer one-click pruning, but you can also run a manual query:
DELETE FROM wp_posts WHERE post_type = 'revision';
Follow it with:
DELETE pm FROM wp_postmeta pm LEFT JOIN wp_posts p ON pm.post_id = p.ID WHERE p.ID IS NULL;
That clears orphaned post meta tied to deleted revisions. On a 500-post site with twenty revisions per post, you might recover 200–500 MB of database storage. On larger content operations, the savings can hit multiple gigabytes.
After deletion, run OPTIMIZE TABLE wp_posts; and OPTIMIZE TABLE wp_postmeta; to reclaim the freed space and rebuild indexes. Most managed WordPress hosts (including BigScoots) run nightly optimization, but manual pruning is faster if you’re migrating or cloning a site.
One non-obvious consequence: backup size and restore time
Revisions don’t just eat disk—they inflate every database backup. If your nightly backup routine dumps the entire database to S3 or a remote server, a bloated wp_posts table means longer backup windows, higher transfer costs, and slower restores when you need to roll back.
A 2 GB database with 1.5 GB of revisions takes three times as long to restore as a pruned 500 MB copy. If you’re running automated staging-site clones or testing migrations, trimming revisions before export cuts minutes—sometimes hours—off the process.
If you’re managing a high-frequency content site, set WP_POST_REVISIONS to 3–5 in wp-config.php today. You’ll keep enough history to recover from mistakes without letting old drafts compound into database drag. And if you’ve never pruned, run a one-time cleanup and watch your backup size drop.
Got a WordPress infrastructure question? Reply and we’ll cover it in a future issue.