Performance
Database bloat: what autoloaded options are costing you
4 August 2026 · 6 min read
On this page
Database bloat is the least visible performance problem on WordPress. It does not show in a PageSpeed report, it does not correlate with anything you changed, and it makes every single page slower for every single visitor.
Autoloaded options: the one that matters
WordPress loads a set of options on every request, before anything else happens. That is the wp_options table, rows marked autoload = yes.
This is by design and normally fine. The problem is that plugins add autoloaded options and many never remove them on uninstall. Over years, that accumulates.
A healthy site: under 1MB autoloaded. Problems start around 1MB. Over 3MB is a real drag on every page.
To check, run this in phpMyAdmin:
SELECT SUM(LENGTH(option_value))/1024/1024 AS mb FROM wp_options WHERE autoload IN ('yes','on','auto','auto-on');
And to see the worst offenders:
SELECT option_name, LENGTH(option_value)/1024 AS kb FROM wp_options WHERE autoload IN ('yes','on','auto','auto-on') ORDER BY kb DESC LIMIT 25;
That second query is usually revealing. You will typically find several hundred kilobytes belonging to a plugin you removed two years ago.
The other kinds of bloat
Expired transients. Temporary cached values that should clean themselves up and frequently do not. Thousands of rows is common and safe to clear.
Post revisions. Every save of every page keeps a full copy. A site with 500 pages edited regularly can carry 10,000 revisions.
Spam and trashed comments. Sitting in the database indefinitely unless emptied.
Orphaned postmeta. Metadata belonging to posts that no longer exist, usually left by removed plugins.
WooCommerce sessions and logs. On shops, these tables grow fast and are frequently the largest thing in the database.
Cleaning up safely
Back up the database before touching any of this. Deleting the wrong row breaks things in ways that are hard to diagnose, and this is the one area where an undo is genuinely necessary.
The safe automated part. WP-Optimize or similar handles expired transients, spam comments, trashed posts and orphaned metadata without much risk. Run it, with a backup taken first.
Limit revisions going forward. Add to wp-config.php:
define( 'WP_POST_REVISIONS', 5 );
Then clear the old ones with the same cleanup plugin.
The autoload part needs judgement. For each large autoloaded option, work out which plugin owns it by searching the option name. If the plugin is gone, the option can usually be deleted — or safer, set to autoload = no first, which stops it loading on every request while leaving the data intact.
That is the conservative move: change autoload rather than delete. If something breaks, you can put it back.
What not to delete: anything belonging to an active plugin, core options like siteurl and home, and anything you cannot identify. "I do not recognise it" is not the same as "it is unused".
How much difference it makes
Honest answer: less than hosting, less than caching, less than images — and more than you would expect on a site that has been running for years.
Going from 5MB autoloaded to 500KB typically takes 100–300ms off every page load, including for logged-in users and dynamic pages where caching does not help. On a slow site it is noticeable; on an already-fast site it is marginal.
It also makes backups smaller and faster, which matters more than it sounds when you need to restore one.
How often
Quarterly is enough. This is not a weekly job — databases do not bloat quickly, and the risk of repeated cleanup passes outweighs the benefit.
It is on the maintenance checklist as a quarterly item for that reason, and it is included in our care plans — mostly because it is the task people are least comfortable doing themselves, and the one where a mistake is hardest to notice.