Bloated WordPress database: how to clean revisions, transients and orphaned tables

Do you have a WordPress site that feels slower and slower, even though you haven't added new content in months? Often the problem isn't on the frontend at all, it's in the database. WordPress and its plugins quietly write tens of thousands of rows that nobody will ever read again: old post revisions, expired temporary options, leftover meta from uninstalled plugins, and entire tables nothing uses anymore.

The good news is that most of this junk can be cleared without breaking anything, as long as you know what you're looking for and take a backup first. In this article I'll show you exactly what accumulates, how to tell what's safe to delete, and how to keep the database lean long term, without relying on magic promises.

What actually bloats the database

Before you delete anything, it helps to understand where the weight comes from. The usual culprits are a few:

• Post revisions: every time you save an article, WordPress stores a copy. A frequently edited post can carry dozens of revisions, each duplicating the full content.
• Expired transients: temporary data stored in the wp_options table. They're supposed to expire on their own, but they often get stuck.
• Autoloaded options: options flagged to load on EVERY page. When plugins dump hundreds of KB here, they slow down the whole site.
• Spam and trashed comments, old transactions and logs.
• Orphaned meta: rows in wp_postmeta or wp_usermeta pointing to content that no longer exists.

Not everything large is useless. The goal is to separate real junk from the data you use daily.

How to see what takes up space, without guessing

Don't clean blindly. Measure first. In phpMyAdmin (found in cPanel with most hosts) open the database and sort tables by size. You'll almost certainly see wp_options, wp_postmeta and possibly plugin-added tables at the top.

A critical point is autoloaded options. Run a simple query in the SQL tab:

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

If the result runs into hundreds of KB or more, you have a real performance problem, because that data is read on every single page load. You can also list the biggest offenders to see which plugin left them.

If your prefix isn't wp_, replace it everywhere. Measure before and after, so you know what you actually gained.

Safe cleanup, step by step

The golden rule: take a full database backup before any deletion. No backup, no touching anything.

• Limit revisions: add define('WP_POST_REVISIONS', 5); to wp-config.php so you only keep the last few per post from now on.
• Delete old revisions and expired transients with a trusted cleanup plugin (for example an established optimization one), which does the job without risky hand-written queries.
• Empty the spam and comment trash.
• For autoload, switch heavy options left by gone plugins from 'yes' to 'no', or delete them if you're sure the plugin is gone.

After cleanup, run Optimize on the tables to reclaim the physical space freed. Test the site immediately: main pages, contact form, checkout if it's a shop.

Orphaned tables: the tricky part

When you uninstall a plugin, most do NOT drop their tables. They stay there, with names like wp_redirection_logs or wp_mailpoet_x, taking up space forever.

This is where caution matters, because dropping a table is irreversible without a backup:

• List the tables that don't start the classic way (posts, options, postmeta, etc.) and search each prefix on Google.
• Confirm the associated plugin really is uninstalled and you don't plan to reactivate it.
• Delete one at a time, with a fresh backup first, not in bulk.

If you have any doubt about even a single table, leave it. A few extra MB harm nothing; a wrongly deleted table can break a feature. Caution beats perfect cleanliness.

How to keep it clean (and when to call someone)

Cleanliness isn't a one-off event, it's maintenance. A few habits that matter:

• Keep WP_POST_REVISIONS set to a sensible number, permanently.
• Install only plugins you actually need, and uninstall unused ones (then check the leftover tables).
• Schedule periodic optimization and run automatic backups.

If you look at phpMyAdmin and feel you don't want to touch anything for fear of breaking the site, that's completely normal, especially on a shop with real orders. At MPO Web Studio we do this remotely, safely, with a backup before and a check after, for clients across the country. If you'd like a hand or just a second opinion, message us on WhatsApp and we'll look together. No magic promises, just a database that breathes again.