Does cleaning up the WordPress database really improve performance?

It depends on how much ballast has accumulated. The most effective lever is bloated autoload data, which WordPress loads on every single page request – cleaning that up makes a noticeable difference. Deleting revisions and transients makes the database smaller and backups faster, but usually has a smaller effect on load time. So: measure before and after, rather than blindly running a plugin.

What is autoload and why does it matter?

In the wp_options table, options have an autoload flag. Everything with autoload = yes is loaded into memory automatically on EVERY page request – regardless of whether the page needs it. Abandoned plugins often leave large amounts of data here, which then gets dragged along needlessly on every request. Finding and removing these autoload leftovers is the biggest database performance lever.

How often should I clean up the WordPress database?

For most sites, once or twice a year is enough, plus a one-off after removing larger plugins, because they often leave their autoload options behind. For very active sites with many posts and plugins, a quarterly rhythm can make sense. More important than frequency is permanently limiting revisions, so not much accumulates in the first place.

Which plugin is good for cleaning up the database?

Established optimisation plugins like WP-Optimize or Advanced Database Cleaner handle revisions, transients and spam safely and offer a backup first. For targeted cleanup of autoload leftovers, a direct look via SQL is often more precise. In both cases: back up first, then clean up – a wrongly deleted option can take a site down.

Clean Up and Optimise the WordPress Database

The database is your WordPress site’s memory – and it grows with every post, every plugin and every saved setting. Over time, ballast accumulates that slows down every page build a little and bloats your backups. Cleaning it up pays off when you know where to start – and measure before and after, instead of blindly clicking a plugin.

Where the Ballast Accumulates

These places are almost always affected:

Post revisions: WordPress stores every intermediate version. For long texts, that quickly adds up to many times the actual content.
Transients: cached, supposedly temporary plugin data that doesn’t always expire cleanly and then lingers as leftovers.
autoload data in wp_options: options with autoload = yes are loaded on every page request. Abandoned plugins often leave large amounts of data here that WordPress needlessly drags along on every request. This is the most important point.
Trash and spam: deleted posts in the trash, spam and rejected comments along with their metadata.
Orphaned metadata: postmeta and commentmeta entries whose post or comment was deleted long ago – often left behind by uninstalled plugins.

Measure First

Before you delete anything, look at the situation. This SQL query (in phpMyAdmin) reveals the size of the autoload data:

SELECT ROUND(SUM(LENGTH(option_value))/1024/1024, 2) AS autoload_mb
FROM wp_options WHERE autoload = 'yes';

If the value is well above ~1 MB, take a closer look at which options are so large:

SELECT option_name, ROUND(LENGTH(option_value)/1024, 1) AS kb
FROM wp_options WHERE autoload = 'yes'
ORDER BY LENGTH(option_value) DESC LIMIT 20;

If names of plugins you removed long ago show up here, you’ve found your candidates.

Clean Up in a Targeted Way

Limit revisions instead of just deleting once. In wp-config.php:
```
define( 'WP_POST_REVISIONS', 5 );
```
This keeps a maximum of five revisions per post – the rest never accumulates in the first place.
Remove transients and old revisions – most safely via an established optimisation plugin that offers a backup first, or via targeted SQL if you know what you’re doing.
Identify autoload leftovers from abandoned plugins (see the query above) and set them to autoload = no or delete them – a backup is mandatory here.
Empty trash and spam – regularly, not once; WordPress can also discard comment spam automatically after 15 days.

Remove Table Overhead

After deleting, MySQL/MariaDB often leaves “overhead” behind – reserved but no longer used space. An OPTIMIZE TABLE frees it and defragments the table. In phpMyAdmin this works with a click via “Optimize table”; most optimisation plugins do it too. On very large tables it can lock briefly – so better outside peak hours.

Important: make a backup before any database operation. A wrongly deleted option can take a site down.

Measure Afterwards

Run the same autoload query again and check the load time (PageSpeed Insights). That’s the only way to know whether the cleanup actually helped – rather than just feeling good. If the autoload value drops from several MB to a fraction, you’ve removed real ballast; if it barely moves, the problem was elsewhere.

How Often, and How It Stays Clean

A one-off cleanup fizzles out if the ballast just accumulates again. More sustainable is the combination: permanently limit revisions, let spam be discarded automatically, and check for autoload leftovers specifically after removing larger plugins. For most sites, a deliberate look once or twice a year is then enough. Exactly this kind of regular check is part of our WordPress maintenance.

A database that’s completely unreachable is a different problem → Error establishing a database connection. Otherwise, the database is one of the levers feeding into Core Web Vitals, alongside caching.

Want to know what’s really slowing your database down, without writing SQL yourself? Drop us a line – we’ll measure, clean up safely and show you the difference.