The slowdown you cannot see: WordPress database bloat
Post revisions, expired transients, orphaned metadata and old plugin tables quietly turn a fast site into a slow one, and no amount of caching hides it from logged in users.
Engineering·30 August 2026·6 min read
A site that was quick two years ago is now sluggish, especially in the admin, and nothing obvious has changed. The theme is the same, the images were optimised, caching is on. The slowdown is underneath, in a database that has been accumulating debris since launch.
This is the least visible performance problem in WordPress and one of the most common, because nothing about it announces itself.
Where the weight comes from
- Post revisions. WordPress keeps every draft state by default, forever.
- Transients. Temporary cached values that expire but are frequently never cleaned up.
- Orphaned metadata. Rows left behind by deleted posts, products and users.
- Abandoned plugin tables. Plugins deactivated years ago whose tables and options remain.
- Autoloaded options. Large values loaded on every request whether or not the page needs them.
- Spam and trashed comments nobody ever emptied.
Why caching hides it, and from whom
Page caching serves a stored HTML copy to anonymous visitors, so the database barely gets touched for them. That is why a bloated site can still score well in a speed test.
The people who feel it are the ones who cannot be cached: logged in users, customers with a cart, and your own team in the admin. On a WooCommerce store that means every buyer at exactly the moment you least want friction.
Clean it in this order
- Take a full backup. This is not optional and there is no version of this article where it is.
- Empty spam and trash, then clear expired transients.
- Delete old post revisions and set a sane limit going forward.
- Remove orphaned postmeta, usermeta and term relationships.
- Look at the largest autoloaded options and deal with the offenders.
- Drop tables belonging to plugins you removed long ago, once you have confirmed what they are.
- Finally, optimise the tables so the storage engine reclaims the space.
Stop it coming back
Cleaning is a one time gain. Not accumulating is a permanent one. Cap revisions, schedule the cleanup rather than doing it by hand, and be disciplined about removing plugins properly instead of deactivating them and moving on.
On stores, watch the order and session tables specifically. High volume WooCommerce sites accumulate session and log rows faster than anything else, and they are the tables that hurt checkout.
Automating the boring part
SmartSite Optimizer includes database cleanup alongside the asset side of performance, so revisions, transients and orphaned rows get handled on a schedule instead of when someone remembers. It is the least visible thing the plugin does and often the one that makes the admin usable again.
For the front end half of the story, see what actually moves LCP and caching explained.
If your site feels fast to strangers and slow to you, the database is the first place to look. Back up, clean, cap what accumulates, and the admin you dread opening becomes usable again.
Frequently asked questions
Why is my WordPress admin slow when the site is fast?
Because page caching serves visitors a stored copy while the admin executes real queries every time. A slow admin with a fast front end is the classic signature of a bloated database, usually an oversized options table or a huge postmeta table.
What is autoload and why does it matter?
Options marked autoload are loaded into memory on every single request, including front end ones. Plugins that store large values there, and plugins that were removed without cleaning up, can leave megabytes being read on every page load. It is one of the highest impact and least known WordPress performance checks.
Is it safe to delete post revisions?
Generally yes, once you have a backup, and it is worth limiting how many are kept going forward rather than deleting periodically. A site with a thousand posts and thirty revisions each is carrying thirty thousand rows it will never read.