How to Clean Up a Bloated WordPress Database Safely

To clean up a bloated WordPress database, start with a full backup, then work through four areas in order: large autoloaded options, expired and orphaned transients, excess post revisions, and tables or data left behind by removed plugins. Measure before and after so you know the cleanup helped. Most of the speed gain usually comes from the first item.

This guide shows how to find each problem, how to fix it safely, and how to stop it from coming back.

Why WordPress databases get bloated

WordPress stores almost everything in a MySQL or MariaDB database: posts, pages, settings, users, orders and plugin data. Over the years, that database collects things nobody needs anymore:

• Settings saved by plugins you uninstalled years ago.
• Temporary cached data that was never cleared.
• Dozens of saved revisions for every page.
• Whole tables created by plugins that are long gone.

This is a form of technical debt. It does not break anything on its own, but it makes the site slower, backups bigger and migrations harder. Database size is one of the things we check when we measure WordPress technical debt.

Signs your database needs attention

You do not need to clean the database on a schedule just because. Look for these signs first:

• Admin pages are slow, even when the front end is cached. Autoloaded options load on every request, including in the dashboard, so heavy options show up there first.
• Site Health warns about autoloaded options. This is the clearest signal on WordPress 6.6 and later.
• Backups and migrations take much longer than they used to, or a host warns that the database is near its size limit.
• One table is far larger than the others. A huge wp_options table on a small brochure site is a red flag. So is a log table from a security or email plugin that grows forever.
• Query Monitor shows slow queries against wp_options or wp_postmeta on staging.

If none of these apply, the database is probably not your problem, and your time is better spent elsewhere.

Before you touch anything

Database cleanup deletes data. Treat it with care:

1. Take a full database backup and confirm you can restore it.
2. Work on a staging copy first, then repeat the steps on production.
3. Write down the starting numbers: total database size, the largest tables and the total size of autoloaded options.
4. Never delete something just because a tool flagged it. Find out what created it first.

If you use WP-CLI, the WordPress command-line tool, these two commands give you a quick baseline:

# Size of each table, largest first
wp db size --tables --orderby=size --order=desc

# Export a backup before making changes
wp db export before-cleanup.sql

Step 1: Find heavy autoloaded options

What autoloading means

The wp_options table stores site settings. Each row has an autoload flag. When it is set, WordPress loads that option into memory on every single page request, whether the page needs it or not. A few kilobytes is fine. Several megabytes of autoloaded data slows down every request, including admin pages.

What changed in WordPress 6.6

WordPress 6.6 changed how autoloading works, as described in the WordPress core announcement on autoload changes:

• The autoload column now uses the values on, off, auto, auto-on and auto-off, in addition to the older yes and no.
• When a plugin does not say whether an option should autoload, WordPress decides. Options larger than 150,000 bytes are no longer autoloaded by default in that case.
• The Site Health screen warns when the total size of autoloaded options is above 800 KB.

These changes help new data, but they do not clean up large options that were saved before you updated. Older sites often still carry them.

How to find the largest autoloaded options

This SQL query lists the 20 largest autoloaded options. It uses the same set of values that WordPress itself treats as autoloaded. Replace wp_ if your table prefix is different.

SELECT option_name, LENGTH(option_value) AS bytes, autoload
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto-on', 'auto')
ORDER BY bytes DESC
LIMIT 20;

Then look at each large option and ask two questions:

• Which plugin or theme created it? The option name usually starts with the plugin’s prefix.
• Is that plugin still installed and active?

How to fix them

• Option belongs to a removed plugin: export it to a file as a record, then delete it.
• Option belongs to an active plugin but is only needed on some pages: turn off autoloading for it, test on staging, and watch for errors. With WP-CLI: wp option set-autoload option_name off.
• An active plugin keeps creating huge autoloaded options: report it to the plugin author or look for an alternative. Cleaning up will not help if the plugin refills it tomorrow.

Step 2: Clear expired and orphaned transients

Transients are temporary cached values that plugins store with an expiry time. Without a persistent object cache such as Redis or Memcached, WordPress stores them in the wp_options table.

WordPress has a scheduled task that removes expired transients, but it depends on WP-Cron running, and some transients are saved with no expiry at all. Over time they can pile up into thousands of rows.

With WP-CLI:

# Delete transients that have already expired
wp transient delete --expired

Deleting all transients, not just expired ones, is also generally safe, because plugins are supposed to rebuild missing transients. Expect a few slower page loads afterward while caches refill. Do this on staging first if the site is busy.

If you see a very large number of transients coming back quickly, find out which plugin creates them. That is a code problem, not a cleanup problem.

Step 3: Limit post revisions

Every time someone saves a post or page, WordPress keeps a revision. That is a useful safety net, but a page edited hundreds of times stores hundreds of full copies.

First, set a sensible limit in wp-config.php so the problem stops growing. The WP_POST_REVISIONS constant is documented in the WordPress guide to editing wp-config.php:

// Keep the last 10 revisions of each post
define( 'WP_POST_REVISIONS', 10 );

WordPress only trims extra revisions for a post when that post is saved again, so pages nobody edits keep every old revision. To remove those, a reputable cleanup plugin or a careful WP-CLI command on staging both work. Talk to your editors first: some teams rely on old revisions as a record of what changed.

Step 4: Remove orphaned tables and leftover data

When you delete a plugin, its database tables and options often stay behind. Some plugins clean up after themselves on uninstall. Many do not.

Find tables nobody uses

Compare the list of tables in your database with the plugins you actually run. Table names usually include the plugin’s prefix, so unknown tables tend to stand out. For each one:

1. Search the codebase for the table name to confirm nothing still uses it.
2. Check when it was last written to, if your database tools show that.
3. Export it to a file before dropping it, and keep that file for a while.

Clean up orphaned metadata

Metadata tables like wp_postmeta can hold rows that point to posts that no longer exist. This query counts them:

SELECT COUNT(*)
FROM wp_postmeta pm
LEFT JOIN wp_posts p ON p.ID = pm.post_id
WHERE p.ID IS NULL;

If the number is large, delete those rows on staging first and check that the site still works. On WooCommerce sites, be extra careful and test orders, products and customer accounts afterward.

Step 5: Measure again

After cleanup, repeat your baseline:

• Total database size and largest tables.
• Total size of autoloaded options.
• Site Health status.
• Server response time and admin page speed.

If the numbers barely moved and the site is still slow, the database probably was not the main cause. Our guide on why a WordPress site is slow covers the full diagnostic order. Database server settings also matter; see our article on WordPress server tuning with PHP-FPM, OPcache and Redis.

Keep it clean

A one-time cleanup helps, but the database will grow again unless you change habits:

• Remove plugins properly, using their own uninstall options where they exist.
• Set a revision limit so new revisions do not pile up.
• Use a persistent object cache on busy sites so transients do not live in the options table.
• Check autoloaded size as part of regular maintenance. Our article on what WordPress maintenance includes explains where this fits.
• Review the database during each technical debt audit, so you catch new bloat early. The WordPress technical debt audit checklist includes it.

Need a hand?

If your database is large, your site is slow and you are not sure what is safe to remove, our performance review finds the real cause and cleans up safely on staging first. Contact us with a little detail about your site and we will take a look.

Frequently asked questions

How much autoloaded data is too much in WordPress?

Since WordPress 6.6, the Site Health screen warns when autoloaded options add up to more than 800 KB. Many healthy sites are well under that, so treat it as a ceiling, not a target.

Is it safe to delete transients in WordPress?

Generally yes. Transients are temporary cached data, and plugins are expected to rebuild them when they are missing. Expect a few slower page loads while caches refill, and always have a backup first.

Should I use a database cleanup plugin?

A cleanup plugin is fine for routine jobs like expired transients and old revisions. Be careful with features that delete tables or options automatically, because a tool cannot always tell whether an inactive plugin's data is still needed.

Will cleaning my database make my site faster?

It helps most when the problem is large autoloaded options or huge tables that slow down queries. If your database is small and tidy, cleanup will not change much, and the slowness is coming from somewhere else.