The slowest thing on most WordPress sites is the database nobody maintains
Revisions, expired transients, orphaned metadata and bloated autoloaded options accumulate quietly for years. Cleaning them is routine work, which makes it exactly the sort of thing that should run on a schedule.
Free during early access. No credit card required.
Database bloat is invisible until it is not
WordPress accumulates data it never cleans up. Every post revision is a row that stays forever by default. Every plugin that stores a transient without an expiry leaves it in the options table indefinitely. Deactivated plugins routinely leave their settings, tables and metadata behind entirely.
The most consequential of these is the autoloaded options table, because WordPress loads every autoloaded option on every single page request. A site with two megabytes of autoloaded options is doing two megabytes of unnecessary work before it renders anything, on every request, for every visitor.
None of this triggers an alert. The site gets gradually slower over years, the client attributes it to their hosting, and the agency upgrades the hosting plan rather than deleting eleven thousand post revisions. The upgrade works, which is why the actual cause is rarely found.
What accumulates
- Post revisions, often thousands per long-lived page
- Expired and orphaned transients in the options table
- Autoloaded options from plugins removed years ago
- Orphaned post and user metadata with no parent record
- Spam and trashed comments never purged
- Tables left behind by deactivated plugins
- Session and cart data on WooCommerce sites
Cleaned on a schedule, with a way back
Database changes are irreversible in a way file changes are not, so every optimisation takes a restore point first. This is not optional and cannot be disabled.
Analysis before action
Each site is analysed for table sizes, autoloaded option weight, revision counts and orphaned records. You see what would be removed and how much it would recover before anything runs.
Restore point taken
A database backup precedes every optimisation without exception. Cleanup that goes wrong is not recoverable by re-running anything, so the safety net is mandatory rather than a setting.
Cleanup by policy
You set what is cleaned and how aggressively per site: revision retention, transient expiry handling, orphaned metadata, spam comments, and whether to touch tables from removed plugins.
Verified and reported
The site is checked after optimisation and the space recovered is recorded, so the improvement appears in the client report as a concrete number rather than a claim.
What can be optimised
Revision control
Trim historic revisions to a retention count you set, per site. Long-lived pages frequently carry thousands.
Transient cleanup
Remove expired transients and orphaned ones left by plugins that never set an expiry.
Autoloaded options
Identify and reduce the options loaded on every request, which is usually the single biggest performance win available.
Orphaned metadata
Post and user metadata with no surviving parent record, common after bulk deletions and migrations.
Table optimisation
Reclaim space from fragmented tables after large deletions, where supported by the database engine.
Store-aware handling
Session and expired cart data on WooCommerce sites, cleaned without touching order records.
What optimisation will not fix
Database optimisation is genuinely worth doing and it is routinely oversold. It will not rescue a site that is slow because of an unoptimised theme, uncompressed images, twelve render-blocking scripts or hosting that is inadequate for the traffic.
Where it does help substantially is sites that have been running for years, sites that have been through several plugin regimes, and sites with heavy editorial history. On those the improvement can be dramatic, particularly where autoloaded options have grown past a megabyte.
Treat it as hygiene rather than as a performance strategy. Run it on a schedule, report the space recovered, and look elsewhere when a site is slow despite a clean database. Claiming a database cleanup fixed a fundamentally slow site is the kind of thing clients eventually notice.
Rules worth keeping
- Never optimise without a database restore point
- Do not delete plugin tables without knowing what they hold
- Keep some revisions; retention of zero is a support ticket waiting
- Schedule outside peak hours, especially on stores
- Never treat cleanup as a substitute for real performance work
Questions about database optimization
With a restore point taken first, yes, and we take one before every run without exception. Without a backup it is genuinely risky, because database deletions cannot be undone by re-running anything.
It varies enormously. On a long-lived site with heavy autoloaded options the improvement can be substantial. On a well-maintained recent site it may be negligible. The analysis step tells you what is there before you decide it is worth running.
Monthly is ample for most sites. Weekly for high-volume publications or busy stores where transients and sessions accumulate quickly. More frequently than that is rarely useful.
No. Published content, pages, media records and orders are never touched. What is removed is revisions beyond your retention setting, expired transients, orphaned metadata and spam comments, all of which you control per site.
Stop paying for hosting to hide database bloat
Scheduled analysis and cleanup across every site, always with a restore point, with recovered space reported to the client.
Free during early access. No credit card required.