This post contains affiliate links. If you buy something through one of them, Veravix may earn a commission at no extra cost to you.
Most “optimize your WordPress database” guides jump straight to a plugin and a big green button. That skips the part that actually explains why a database gets slow in the first place, and it means the cleanup often misses the single biggest offender: a bloated wp_options table with too much data flagged to load on every single request.
Here’s what’s actually happening, and the order that fixes it safely.
What actually bloats a WordPress database
Four things build up over time, and only one of them behaves the way most articles imply.
Post revisions. WordPress saves a full copy of a post every time you hit save, with no limit by default. A post edited 40 times has 40 revision rows sitting in wp_posts forever.
Transients. Temporary cached data (an API response, a computed value) that plugins store with an expiration time. When that expiration isn’t cleaned up properly, expired transients pile up as dead rows.
Trashed and spam content. Deleted posts and spam comments sit in the trash tables until something empties them, which nothing does automatically on most sites.
Autoloaded options, the one that actually matters most. Every row in wp_options can be flagged autoload = yes, which means WordPress loads it into memory on every single page load, admin or frontend, cached or not, in one query at the very start of the request. Plugins are supposed to set this flag to “no” for anything that isn’t needed on every page. Most don’t bother. A single abandoned plugin that left a 4MB autoloaded option behind adds that same tax to every page on the site, permanently, until someone finds and removes it. As a rough guide, total autoloaded data under roughly 800KB to 1MB is healthy; past 3 to 5MB it’s worth investigating, and 10MB or more is a real, measurable performance problem.
This is the reason two sites with an identical page-builder and plugin stack can have very different admin-dashboard speeds: one has a clean options table, the other is quietly loading megabytes of dead data on every request.
Back up before touching any of this
Every step below is a database write, and revision or postmeta cleanup on a site using a page builder (Elementor, ACF-driven layouts) or SEO plugin can occasionally remove data those plugins expected to still be there. Take a real database backup, not just a file backup, before running anything. This is the one step worth never skipping, even on a small site.
The safe cleanup order
1. Delete expired transients first. These are the lowest-risk cleanup: they’re meant to be temporary, and anything expired is safe to remove. Via WP-CLI: wp transient delete --expired.
2. Clean up revisions, but don’t delete them all blind. Rather than purging every revision on every post, cap how many WordPress keeps going forward by adding define('WP_POST_REVISIONS', 5); (or a number that fits your workflow) to wp-config.php, then clean up the existing backlog: wp post delete $(wp post list --post_type='revision' --format=ids) (with a backup already taken, per above).
3. Empty trash and spam. Trashed posts and pages, and spam-flagged comments, can be cleared through wp-admin directly (Posts → Trash → Empty Trash, Comments → Spam → Empty Spam) or via WP-CLI’s comment and post delete commands.
4. Run a table optimize pass. After rows are actually deleted, the database tables themselves still reserve the old space until they’re optimized. wp db optimize runs MySQL’s table-optimize routine across the whole database in one command.
5. Audit autoloaded options last, since this is where the real win usually is. A query like wp db query "SELECT option_name, LENGTH(option_value) AS size FROM wp_options WHERE autoload='yes' ORDER BY size DESC LIMIT 20;" shows the heaviest autoloaded rows by name. Anything belonging to a plugin that’s no longer installed is safe to remove; anything unfamiliar is worth searching before deleting, since a handful of large autoloaded options are legitimate (a page builder’s own settings, for instance).
Plugin options, if you’d rather not use WP-CLI
WP-Optimize and Advanced Database Cleaner both cover revisions, transients, and trash/spam cleanup through a plugin UI, including a scheduled cleanup option so this doesn’t need repeating by hand. Neither one surfaces the autoload-size audit as clearly as the manual query above, so that step is worth doing separately even when using one of these plugins for the rest.
If the site is already running WP Rocket for caching, its Database tab covers the same revisions/transients/trash cleanup without adding a second plugin just for this.
How often this actually needs doing
For most sites, a real cleanup pass every few months is enough, unless the site publishes very frequently or runs a plugin known to be autoload-heavy (some SEO and page-builder plugins are repeat offenders). The revision cap in wp-config.php is a one-time fix that stops the backlog from rebuilding; the autoload audit is worth repeating any time the site feels slower in wp-admin specifically, since that’s the symptom a bloated options table produces first.
Etienne Basson works with website systems, SEO-driven site architecture, and technical implementation. He writes practical guides on building, structuring, and optimizing websites for long-term growth.