Available for projects & agency overflow · Quick reply, from the person who does the work

Send a message contact@allaux.fr
FR EN TR
allaux.
Emergency Discuss my project

Cleaning up a WordPress database after years of plugins

Orphaned tables, bloated autoloaded options, accumulated revisions: what an ageing database actually contains and how to clean it up without breaking a plugin still in use.

Describe my issue Send a message

What a database really holds after years of use

A WordPress site several years old, having gone through many plugins installed then removed, accumulates elements in its database that no one ever cleaned up. Well-built plugins delete their own tables on uninstall; many don’t, leaving orphaned tables that keep existing with no active code reading them any more. The wp_posts table also accumulates content revisions: every autosave or manual save of a post creates a new row, never purged by default. Transients, a temporary caching mechanism stored in wp_options, logically expire but often stay in the database long after expiry if nothing purges them.

Orphaned metadata follows the same pattern: when a post, product or customer is deleted, the matching rows in wp_postmeta or wp_usermeta aren’t always removed at the same time, particularly if the deletion went through a direct database query rather than the WordPress interface. These orphaned rows never show up anywhere, but they still bloat the database for no reason.

The most costly point for performance is often the least visible: options flagged autoload in wp_options. These are settings WordPress loads fully into memory on every page load, regardless of whether that page actually needs them. On an old site, this table can reach several megabytes of autoloaded options, loaded on every request even on a plain product page that needs none of them.

How I clean up an ageing WordPress database

  1. Full database backup

    Before any deletion, a backup of the entire database, restorable independently of the site’s files.

  2. Identifying orphaned tables

    I compare the full list of database tables against the prefixes of plugins actually active on the site. A table whose prefix matches no installed plugin, active or not, is a candidate for removal.

  3. Purging revisions and expired transients

    I remove content revisions beyond a reasonable number kept per post, and transients whose expiry date has passed.

  4. Measuring autoloaded options before and after

    I record the total size of options flagged autoload before the intervention, then check its reduction afterwards. It’s the most direct indicator of the cleanup’s real effect on performance.

  5. Functional check

    I check that every active plugin still works normally after the purge, particularly those using transients for their own caching.

Related pages

Describe your need in one minute

A few targeted questions so I can reply with an estimate rather than another questionnaire.

origine
catalogue
extensions-premium (facultatif)
conserver (facultatif)
Please provide an email or a phone number so I can get back to you.

Please provide an email or a phone number so I can get back to you.

Frequently asked questions

Why do autoloaded options actually slow the site down?
Because they’re all loaded into memory on every request, including pages that need none of them. The larger their total volume grows, the more every page load pays that cost, even for a plain product page display.
How do you spot an orphaned table without risking an active plugin?
I cross-reference the database’s table list against the prefixes of plugins actually installed, active or not. A table with no matching plugin, active or deactivated, is a good candidate, but I always check before deletion rather than relying on the name alone.
Should all content revisions be deleted?
No, I keep a reasonable number of recent revisions per post for a useful history, and only purge the old backlog that no longer serves anyone.
Can a database cleanup break an active plugin?
Yes, if a deleted table or transients are still read by an active plugin. That’s why the functional check after cleanup focuses first on plugins that used a cache or a dedicated table.
How often should a WordPress database be cleaned up?
There’s no universal frequency: it depends on how many plugins were installed then removed over time and the volume of content. A check once or twice a year is enough on most active sites.

Related pages