Database work · Intermediate · 30 minutes
How to clean up the WordPress database — Clean the Hot Path, Not the Row Count
Your database has grown for five years and you want to know which part of it is actually costing you time on every page load.
The short answer
Measure the autoload table before deleting anything: options marked autoload are read on every single request, so a bloated wp_options is a cost paid by every visitor, while a million tidy revisions mostly just inflate your backups. Query the autoloaded size first, and you will know within a minute whether this is a performance job or a housekeeping one.
Then work in order of damage: expired transients, autoloaded leftovers from removed plugins, post revisions, and finally the residue of spam comments and orphaned metadata. Take a backup first, because every one of those steps is a DELETE with a friendly button on it.
By the HostingFast team · Reviewed 24 August 2026
Intermediate
Depth assumed
5
Checkpoints end to end
Free
Cost of asking us
Proven
Verified where you'll run it
This is written for someone who will happily open phpMyAdmin or run a query over SSH. The tools matter less than the order: measure, delete the hot path, then cap the thing that regrows.
One warning up front. 'Optimise' in a plugin's interface means 'delete rows', and there is no undo inside that interface. The backup step is not ceremony.
Measure the autoload table first
`SELECT SUM(LENGTH(option_value)) FROM wp_options WHERE autoload = 'yes';` gives you the payload WordPress loads on every request before it renders anything. A few hundred kilobytes is unremarkable; several megabytes is a plugin — usually a removed one — leaving serialised data behind, and it is being read on every page view including cached misses.
Order the same table by length to see the offenders by name. This single query separates a database that is merely large from a database that is genuinely slowing the site down, and it is the difference between an afternoon well spent and an afternoon of deleting revisions for nothing.
Transients and revisions do different damage
Transients are cached values with an expiry that plugins frequently never honour, so they accumulate in wp_options and drag on every request that reads them. Clearing them is quick, safe, and on a long-running site the most visible single improvement available.
Revisions are different. By default WordPress keeps every edit forever, and on an older site that is where the row count lives — but rows in wp_posts that nobody queries cost you backup size and import time far more than page speed. Clear them because they make your dumps unwieldy, not because they are throttling requests.
Delete with a backup and a WHERE clause
Snapshot before the first DELETE. Then work with WP-CLI where you can — `wp transient delete --expired` and `wp post delete $(wp post list --post_type=revision --format=ids)` are bounded, repeatable and scriptable in a way that clicking a plugin's 'clean everything' button is not.
Sweep the residue afterwards: spam comments, trashed posts, orphaned postmeta whose parent no longer exists. None of it earns its keep. Then re-run your autoload query and confirm the number moved, because a cleanup you did not verify is just a cleanup you believe in.
Cap it so this never becomes an excavation
Set `define('WP_POST_REVISIONS', 5);` in wp-config.php, or whatever small number suits your editorial habits. Do it once and every future cleanup is light maintenance rather than a dig through five years of edit history.
If the site is heavy enough that queries are the real bottleneck, the answer is a persistent object cache rather than more deleting — Redis keeps repeat lookups out of MySQL entirely. Query Monitor will tell you which pages are running dozens of queries, and that is a more useful signal than the size of the database on disk.
The stack these queries were run on
Every runbook here was exercised on the platform we actually operate — cPanel, LiteSpeed, NVMe storage, one-click installs — so the phpMyAdmin build and the panel screens match yours rather than a generic host's.
Backups run daily on every plan, and restoring a file or a database is a single click in the panel rather than a support ticket.
- Daily backups, so a DELETE is always reversible
- NVMe SSD storage on every tier, not just the expensive ones
- SSH, Git and Composer on the developer-focused plans
- In-place account upgrades — no migration when you change plan
Why HostingFast
Standard on every plan
One query tells you the answer
The autoloaded size separates a database that is large from a database that is slow, before you delete anything.
Damage ranked correctly
Transients and autoloaded leftovers cost you every request; revisions mostly cost you backup size. Different fixes.
Bounded commands, not a big button
WP-CLI operations you can read, repeat and script, instead of a plugin's one-click 'clean everything'.
Verified afterwards
You re-run the same query to confirm the number moved, because an unverified cleanup is a belief.
Fixed so it stays fixed
Capping WP_POST_REVISIONS once turns every future pass from an excavation into ten minutes.
Scoped honestly
Measuring and clearing the hot path is an intermediate job — about 30 minutes, and less each time after the first.
Quick Start
From order to online
- 1
Measure the autoload payload
`SELECT SUM(LENGTH(option_value)) FROM wp_options WHERE autoload = 'yes';` then order the table by length. This is read on every request, so it is where slowness actually lives.
- 2
Back up before the first DELETE
Whatever the button says, cleaning a database deletes rows. Snapshot first — a restore takes a click here, and an unrecoverable optimise run takes a weekend.
- 3
Clear expired transients
`wp transient delete --expired` clears the cached values plugins forgot to expire. Quick, safe, and usually the most visible single improvement on a long-running site.
- 4
Clear revisions and sweep the residue
Delete the revision backlog, then spam comments, trashed posts and orphaned postmeta. Revisions mostly bloat your backups rather than your page speed — clear them for the dump size.
- 5
Cap revisions, then re-measure
Set WP_POST_REVISIONS to a small number in wp-config.php, then re-run the autoload query to confirm the figure actually moved. If queries are still the bottleneck, a Redis object cache beats more deleting.
Built In
Loaded onto every plan
- Daily backups, with self-service restores you run from the panel
- NVMe SSD storage on every tier, not just the expensive ones
- SSH, Git and Composer on the developer-focused plans
- Per-site PHP version switching from the control panel
- LiteSpeed caching built into the server rather than patched in by plugin
- Staging environments for testing changes before they ship
- cPanel — the control panel most of the industry already runs
- In-place account upgrades — no migration when you change plan
- Human support on duty every hour of every day
- 99.9% uptime as the target, monitored around the clock
Frequently Asked
What people ask us most often
Which part of a big database is actually slowing the site down?
Whatever sits in the hot path. Autoloaded options are read on every request, so a multi-megabyte autoload table costs every visitor; stale transients do the same. A million post revisions are barely queried and mostly inflate your backups and import times. Measure the autoload size first and you will know which of the two problems you have.
Is a plugin's one-click optimise safe to run?
Usually, but it is still a DELETE with no undo inside the interface, and it will happily bundle things you wanted to keep with things you did not. Take a snapshot first, then prefer bounded WP-CLI commands you can read before running. The plugin is fine; running it blind on a five-year-old shop is not.
What happens when the site outgrows its plan?
You upgrade in place. Plan changes happen from the client area with no migration and no downtime, and the range runs from compact shared accounts through VPS up to full dedicated servers. Growth becomes an account setting rather than a hunt for a new host.
Does hosting include mailboxes on my own domain?
Yes — every plan includes mailboxes on your domain, with webmail, IMAP, POP and SMTP plus spam filtering on from the start. There is also standalone email hosting for a domain whose website lives somewhere else entirely.
Keep reading
How to Choose a Domain Name
Pick a name that still reads well in a terminal, an email address and a bill years from now — beginner, roughly an evening of thought.
How to Create a Contact Form
A form visitors finish, sending mail that actually arrives — beginner, about 30 minutes.
Best Drupal vs WordPress
Weighed on the numbers that differ: build model, plugin ecosystem, and what each does to page weight.
WordPress Hosting
WordPress on LiteSpeed and NVMe, with staging clones and daily backups included.
VPS Hosting
KVM virtual servers — root access, DDoS filtering and one flat monthly price.
Changing hosts? Run through our checklist first.
A straightforward sequence for a switch your visitors never feel: which files move first, how to shift email across without losing a single message, the right moment to repoint DNS, and the two mistakes behind almost all the downtime we get asked to rescue.
Give the database faster disks.
NVMe storage and LiteSpeed caching on every tier, daily backups you restore yourself, SSH on developer plans and support that answers at any hour.
View WordPress Hosting plans