# 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.

- Source canonique : [https://allaux.fr/en/wordpress-woocommerce/mise-a-jour/nettoyer-base-donnees](https://allaux.fr/en/wordpress-woocommerce/mise-a-jour/nettoyer-base-donnees)
- Langue : EN
- Dernière mise à jour : 2026-09-30

## Direct answer

> Measure before you delete: list the wp_options rows whose autoload is set to yes and sort them by size, since that is what loads on every request. Then purge expired transients and cap revisions by setting WP_POST_REVISIONS in wp-config.php. Tables left behind by an uninstalled plugin should only go once you have confirmed no active plugin still writes to them.

## 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.

## The point of no return

> Deleting a table without being certain no active plugin still references it is the point of no return in this operation. A plugin might create its table on install but keep reading it even if its companion plugin looks inactive, or silently recreate it on next load without it being noticed right away. Whenever a table is in doubt, I leave it in place or rename it rather than delete it outright.

## How I check the result

> Comparing database size and autoloaded options weight before and after, loading time of a typical page, and no errors in the log during the days following the cleanup. On an old site, the drop in autoloaded volume is often the most telling indicator to show, well beyond a plain megabyte reduction in overall database size.

## Related pages

- **Slow WordPress site** — The most common causes of slowness on a WordPress site or WooCommerce shop, database included. ([/wordpress-woocommerce/site-lent](/wordpress-woocommerce/site-lent))
- **Backing up a shop before an intervention** — What a backup needs to cover before a database operation to stay reversible. ([/guides/sauvegarder-boutique-avant-intervention](/guides/sauvegarder-boutique-avant-intervention))
- **Clearing the WordPress cache** — The difference between page cache, object cache and transients, and how to clear them without breaking anything. ([/guides/vider-cache-wordpress](/guides/vider-cache-wordpress))
- **Glossary: migration** — The technical vocabulary used across these pages, explained simply. ([/glossaire/migration](/glossaire/migration))

## FAQ

### 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.