How to Clean Up and Optimise Your WordPress Database for Better Performance

WordPress databases grow quietly in the background. Every draft you save, every comment that gets flagged as spam, every plugin that stores its settings as an autoloaded option — it all accumulates in the same set of database tables. On a site that’s been running for a year or two, that accumulation can add up to tens of thousands of redundant rows sitting in your database doing nothing useful.

Most of this data is completely harmless, but it has a cost. A bloated database means slower queries, larger backup files, and occasionally sluggish admin performance. On shared hosting where server resources are limited, those costs are more noticeable. Cleaning up your database periodically is one of the simplest maintenance tasks you can do, and it pays dividends in both performance and reliability.

This guide covers what accumulates in a WordPress database, how to clean it safely, and how to keep it lean going forward.

What Builds Up in a WordPress Database

Before cleaning anything, it helps to understand what you’re dealing with. The main sources of database bloat are:

• Post revisions — Every time you save a post or page in the editor, WordPress saves a new revision. A post edited 30 times has 30 stored copies. These are rarely needed after a post is published but WordPress keeps them indefinitely by default.
• Auto-drafts — WordPress auto-saves your work as you type. These auto-draft records accumulate in the posts table and are usually left over from sessions that were closed without being published or discarded properly.
• Trashed posts and pages — Posts you’ve moved to trash remain in the database until you empty the bin. If you never empty it manually, they sit there indefinitely.
• Spam and trashed comments — Spam comments caught by Akismet or WordPress itself are held in the comments table. On a site receiving regular spam, this table grows quickly.
• Transients — Transients are temporary data stored in the wp_options table by plugins. They’re supposed to expire automatically, but expired transients are not always cleaned up, leaving orphaned rows behind.
• Orphaned post meta — When a post or page is deleted, the associated metadata in wp_postmeta is not always removed. The same applies to user meta when users are deleted.
• Unused plugin data — Plugins frequently add their own tables or rows to wp_options. When you deactivate or delete a plugin, that data often stays behind unless the plugin explicitly cleans up after itself.

Before You Clean: Back Up First

Database cleanup is generally safe, but it’s irreversible. Once you delete revisions or orphaned data, it’s gone. Before running any cleanup tool, make sure you have a recent backup of your database. This is non-negotiable — especially on a live site.

If you don’t already have a backup routine in place, set one up before proceeding. A structured WordPress backup schedule ensures you always have a restore point before making changes like this.

How to Clean Your WordPress Database

There are two main approaches: using a plugin or using phpMyAdmin directly. For most site owners, a plugin is the right choice. Direct database access is better suited to developers who are comfortable with SQL.

Option 1: Use a Database Cleanup Plugin

Several plugins handle WordPress database cleanup well. Two of the most widely used are WP-Optimize and Advanced DB Cleaner. Both are available free from the WordPress plugin directory.

WP-Optimize is the more straightforward option for beginners. Here’s how to use it:

1. Install and activate WP-Optimize from Plugins → Add New.
2. Go to WP-Optimize → Database in your admin menu.
3. You’ll see a list of optimisations available — post revisions, auto-drafts, trashed posts, spam comments, expired transients, and more. Each row shows how many items are found.
4. Select the items you want to clean. For a first-time cleanup, I usually select all of them. The plugin shows you counts before you commit, so you can make informed decisions.
5. Click Run all selected optimizations.
6. After cleanup, use the Optimize button to run a MySQL OPTIMIZE TABLE command, which defragments the tables and reclaims freed space.

After running the optimisation, WP-Optimize will show you the space saved. On sites I’ve cleaned after a year or more of activity, it’s common to reclaim anywhere from 20MB to several hundred MB depending on how active the site has been.

Option 2: Clean via phpMyAdmin

If you prefer direct access, phpMyAdmin is available in most hosting control panels. Log in, select your WordPress database, and you can run SQL queries or use the built-in table interface to delete rows manually.

To remove all post revisions, for example, you would run:

DELETE FROM wp_posts WHERE post_status = 'inherit' AND post_type = 'revision';

To clear expired transients:

DELETE FROM wp_options WHERE option_name LIKE '_transient_%' OR option_name LIKE '_site_transient_%';

Note that the default WordPress table prefix is wp_, but yours may differ. Check your wp-config.php file if you’re unsure. After running DELETE queries, go to the Operations tab for each affected table and run Optimize table to reclaim the freed space.

Direct SQL is powerful but unforgiving. A mistake here can corrupt your data, which is exactly why the backup step above is essential.

Controlling Post Revisions Going Forward

Cleaning up existing revisions is a one-time fix. To prevent the same bloat from building up again, add a revision limit to your wp-config.php file. Open the file via your hosting file manager or FTP and add this line before the /* That's all, stop editing! */ comment:

define( 'WP_POST_REVISIONS', 3 );

This tells WordPress to keep a maximum of three revisions per post. That’s enough to roll back a recent mistake without accumulating dozens of copies over time. You can also set it to false to disable revisions entirely, though I’d advise keeping at least a small number for safety.

Managing Autoloaded Options

The wp_options table is where WordPress stores site settings, and it also stores autoloaded options that are loaded on every page request. When plugins leave behind orphaned options — or when they autoload large blocks of data unnecessarily — this table can become a performance bottleneck.

You can check the total size of your autoloaded options by running this query in phpMyAdmin:

SELECT SUM(LENGTH(option_value)) AS total_autoload_size FROM wp_options WHERE autoload = 'yes';

The result is in bytes. If your total autoloaded data exceeds roughly 800KB, it’s worth investigating which options are responsible. WP-Optimize and similar tools can help identify the largest rows, and you can disable autoloading on non-essential plugin options if the plugin doesn’t handle this itself. WordPress 6.4 and later added a built-in mechanism to manage autoloaded options more granularly, so keeping WordPress updated helps here too.

The broader subject of WordPress performance — including caching, image optimisation, and server-level improvements — is covered well in the WordPress developer documentation on optimisation.

Automating Database Cleanup

Running a manual cleanup every few months works fine for small sites. For larger or busier sites, scheduling the cleanup to run automatically is more reliable. WP-Optimize includes a scheduler that lets you set cleanup tasks to run daily, weekly, or monthly. Enable it under WP-Optimize → Settings → Schedule.

The scheduler works through WordPress’s built-in task system. If you want a reliable scheduling setup, it’s worth understanding how WordPress cron jobs work and whether your hosting is configured to run them properly.

Common Mistakes

• Cleaning without a backup — Always back up your database before running any cleanup. It takes a couple of minutes and gives you a safety net if something goes wrong.
• Deleting all revisions on a live, actively edited site — If your team is actively editing posts, deleting all revisions removes the ability to roll back recent changes. Clean older revisions and set a reasonable limit going forward rather than removing everything.
• Running OPTIMIZE TABLE on InnoDB tables during peak traffic — On MyISAM tables, OPTIMIZE TABLE locks the table while it runs. On InnoDB (the modern default), this is less of an issue, but it’s still best to run optimisations during low-traffic periods.
• Ignoring the wp_options table — Most people focus on posts and comments and overlook the options table. Orphaned plugin options and bloated autoloaded data here can be a significant and often overlooked drag on performance.

When Manual Cleanup Makes Sense vs Automation

For small personal sites with low edit frequency, a manual cleanup once every few months is perfectly adequate. A plugin like WP-Optimize makes it a five-minute task. For sites with a lot of editorial activity — multiple authors, frequent publishing, heavy plugin use — automating the cleanup on a weekly or fortnightly schedule saves time and keeps the database consistently lean.

Either way, database cleanup should be part of a broader maintenance routine. Keeping your database lean, running regular backups, and staying on top of WordPress performance as a whole will keep your site stable and fast as it grows over time.

Conclusion

Start with a backup, run WP-Optimize to clear out revisions, transients, spam, and orphaned data, then add a revision limit to wp-config.php to prevent the same bloat from returning. That’s the entire process for most sites — simple, safe, and worth doing at least once a year.