{"id":312,"date":"2025-08-05T00:38:09","date_gmt":"2025-08-05T00:38:09","guid":{"rendered":"https:\/\/donaldvaldez.com\/blog\/?p=312"},"modified":"2026-07-28T22:36:54","modified_gmt":"2026-07-28T22:36:54","slug":"capping-the-bloat-hard-limiting-revisions-and-autosaves-in-wp-config-php","status":"publish","type":"post","link":"https:\/\/donaldvaldez.com\/blog\/capping-the-bloat-hard-limiting-revisions-and-autosaves-in-wp-config-php\/","title":{"rendered":"Capping the Bloat: Hard-Limiting Revisions and Autosaves in wp-config.php"},"content":{"rendered":"

To maintain a fast and scalable server environment, you must limit WordPress post revisions<\/b>. Out of the box, WordPress is designed to save a snapshot of your content almost every time you pause typing. While this is an excellent safety net for writers, it is a nightmare for database administrators.<\/p>\n

Every time a revision or autosave triggers, WordPress writes a brand-new row to your MySQL database. Over months and years of content creation, this mechanism creates massive database bloat, severely degrading your server’s SQL query performance. By implementing a few simple directives in your wp-config.php<\/code> file, you can cap these revisions, drastically reduce your database footprint, and restore backend efficiency.<\/p>\n

The Context: How Gutenberg Bloats the wp_posts Table<\/h2>\n

The core issue stems from how the standard Gutenberg editor interacts with the database. WordPress stores all content\u2014live pages, drafts, menu items, and revisions\u2014inside a single database table called wp_posts<\/code>.<\/p>\n

By default, WordPress places absolutely no limit on the number of revisions it saves. If you spend three hours drafting and formatting a comprehensive technical article, the editor might save a new database row for every minor keystroke change or layout adjustment. It is entirely common for a single published article to generate 100 or more hidden revision rows in the wp_posts<\/code> table.<\/p>\n

If your website has 500 published articles, you could easily have 50,000 useless revision rows bogging down your database. When the server\u2019s SQL engine has to sift through thousands of obsolete rows to find the actual live content, query execution times spike, causing your Time to First Byte (TTFB) to suffer globally.<\/p>\n

The Execution: How to Limit WordPress Post Revisions<\/h2>\n

You do not need a bloated optimization plugin to fix this architectural flaw. The most efficient and permanent way to limit WordPress post revisions is to dictate the rules directly at the server level via your wp-config.php<\/code> file.<\/p>\n

Access your server via SFTP or SSH, open the wp-config.php<\/code> file located in your public root directory, and add the following definitions directly above the line that reads \/* That's all, stop editing! Happy publishing. *\/<\/code>.<\/p>\n

1. Cap the Total Revisions<\/h3>\n

To prevent infinite row generation, force WordPress to only keep a specific number of recent revisions per post. For most enterprise and publishing environments, a limit of 5 is more than enough to provide a safety net without destroying database performance.<\/p>\n

define(\u2018WP_POST_REVISIONS\u2019, 5);<\/code><\/pre><\/p>\n
With this code active, WordPress will automatically delete the oldest revision once the 6th revision is generated, keeping your database completely lean moving forward.<\/p>\n
2. Extend the Autosave Interval<\/h3>\n
In addition to revisions, the WordPress editor fires an AJAX request to the server every 60 seconds to autosave your current progress. If you have multiple authors working in the backend simultaneously, these constant requests consume significant backend PHP bandwidth and CPU cycles.<\/p>\n
You can modify this behavior by extending the interval. Changing the default 60 seconds to 300 seconds (5 minutes) drastically reduces the frequency of these background server hits.<\/p>\n
define(\u2018AUTOSAVE_INTERVAL\u2019, 300);<\/code><\/pre><\/p>\n
Cleaning Up Existing Database Bloat<\/h2>\n
Adding the code above prevents future<\/i> bloat, but it does not retroactively clean up the thousands of revisions already sitting in your database.<\/p>\n
Before finalizing your optimization, you should clear the existing backlog. You can run a simple SQL query directly in phpMyAdmin or your database CLI to instantly delete all old revisions:<\/p>\n
DELETE FROM wp_posts WHERE post_type = \u2018revision\u2019;<\/code><\/pre><\/p>\n
Warning: Always take a full database backup before executing manual SQL deletion commands on a production server.<\/i><\/p>\n
\"Limit
Every autosave bloats your database. Learn the wp-config.php tricks to limit WordPress post revisions and increase database query efficiency.<\/figcaption><\/figure>\n
Frequently Asked Questions<\/h2>\n
[lux_faq htag=\"h3\" open=\"first\" style=\"card\"]<\/pre>\n
Q:Does limiting post revisions speed up a WordPress database?<\/b><\/p>\n
A:Yes. Limiting WordPress post revisions drastically reduces the sheer volume of rows in the wp_posts<\/code> database table. A smaller database footprint allows the server’s SQL engine to execute queries faster, directly improving backend performance and TTFB.<\/p>\n
Q:Can I disable WordPress post revisions entirely?<\/b><\/p>\n
A:Yes. If you do not want any revisions saved at all, you can change the configuration value to false: define('WP_POST_REVISIONS', false);<\/code>. However, keeping a small cap (like 3 or 5) is generally recommended in case a browser crashes during editing.<\/p>\n
Q:Where exactly do I place the code to limit WordPress post revisions?<\/b><\/p>\n
A:The code must be placed in the wp-config.php<\/code> file, above the line that says \/* That's all, stop editing! Happy publishing. *\/<\/code>. If you place it at the absolute bottom of the file, WordPress will ignore the command and continue saving infinite revisions.<\/p>\n
Q:How does the AUTOSAVE_INTERVAL affect server performance?<\/b><\/p>\n
A:By default, the editor pings the server via admin-ajax.php<\/code> every 60 seconds to save data. By extending this to 300 seconds, you reduce the number of PHP executions by 80% during long editing sessions, preserving valuable CPU workers for front-end visitors.<\/p>\n
Q:Will limiting revisions delete my currently published content?<\/b><\/p>\n
A:No. Revisions are stored as a distinct post_type<\/code> in the database. Implementing a cap only affects the historical backup drafts of a post, not the active, published version your users see.<\/p>\n
Securing Your Database Performance<\/h2>\n
Do not let hidden draft data cripple your infrastructure. By taking a proactive stance to limit WordPress post revisions and extend autosave intervals, you ensure your database remains streamlined, scalable, and fully optimized for rapid query execution. Audit your wp-config.php<\/code> file today to instantly lock down your database bloat.<\/p>\n","protected":false},"excerpt":{"rendered":"
To maintain a fast and scalable server environment, you must limit WordPress post revisions. Out of the box, WordPress is designed to save a snapshot of your content almost every time you pause typing. While this is an excellent safety net for writers, it is a nightmare for database administrators. Every time a revision or […]<\/p>\n","protected":false},"author":1,"featured_media":315,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[15],"tags":[60,62,61],"class_list":["post-312","post","type-post","status-publish","format-standard","has-post-thumbnail","category-server-admin","tag-database-bloat","tag-sql-optimization","tag-wp-config-php"],"_links":{"self":[{"href":"https:\/\/donaldvaldez.com\/blog\/wp-json\/wp\/v2\/posts\/312","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/donaldvaldez.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/donaldvaldez.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/donaldvaldez.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/donaldvaldez.com\/blog\/wp-json\/wp\/v2\/comments?post=312"}],"version-history":[{"count":3,"href":"https:\/\/donaldvaldez.com\/blog\/wp-json\/wp\/v2\/posts\/312\/revisions"}],"predecessor-version":[{"id":317,"href":"https:\/\/donaldvaldez.com\/blog\/wp-json\/wp\/v2\/posts\/312\/revisions\/317"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/donaldvaldez.com\/blog\/wp-json\/wp\/v2\/media\/315"}],"wp:attachment":[{"href":"https:\/\/donaldvaldez.com\/blog\/wp-json\/wp\/v2\/media?parent=312"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/donaldvaldez.com\/blog\/wp-json\/wp\/v2\/categories?post=312"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/donaldvaldez.com\/blog\/wp-json\/wp\/v2\/tags?post=312"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}