After a few years of activity, a WordPress site builds up an impressive amount of invisible data: successive versions of the same post, comments that were never approved, settings left behind by plugins uninstalled long ago. None of it shows on screen, but all of it piles up in the database, the very one WordPress queries every time a page loads.

The bigger this database grows, the slower queries become, even on decent hosting. A site that already felt a bit sluggish keeps slowing down over time, with no new plugin and no theme change to explain the drop in speed. The real culprit, often invisible, is the dead weight that has accumulated in the MySQL tables.

Optimising the WordPress database means sorting through this history: removing what no longer serves a purpose, reorganising the tables, and starting fresh from a lighter base. It is simple in principle, but worth handling with method so nothing breaks along the way.

In short: optimising your WordPress database means deleting excess post revisions, spam, expired transients and orphaned tables left by old plugins, then reorganising (optimising) the remaining tables, ideally through a dedicated plugin and after a full backup.

Why the database swells over time

WordPress records far more information than most people imagine for everyday actions:

  • a new post revision on every autosave
  • a database row for every comment received, spam included
  • a temporary entry for every calculation a plugin caches
  • entire tables created by plugins, sometimes never removed after uninstalling

On a site active for several years, these accumulated elements can make the database several times larger than it needs to be, without a single one of those extra bytes serving the content actually displayed.

Post revisions, the first culprit

Every time a post is saved, WordPress keeps a copy of the previous version. That is useful for rolling back a mistake, but with no limit set, a post edited fifty times keeps fifty versions in the database. On an active blog running for years, that quickly adds up to thousands of useless rows in the content table.

Spam and comments awaiting moderation

A site that accepts comments also attracts its share of automated spam. These messages, even when filtered by an anti-spam plugin, often stay stored in the database while awaiting approval or manual deletion. On heavily commented sites, spam alone can account for a significant share of the database's total weight.

Expired transients, the forgotten buffer

Transients are temporary data that WordPress and plugins use to speed up certain calculations: a query result, a piece of data fetched from an external API. They are supposed to clear themselves automatically on expiry, but this mechanism regularly fails, leaving thousands of stale entries to pile up with no use left.

Orphaned tables left by old plugins

When a plugin is deactivated and then deleted, it does not always remove its own tables from the database. These orphaned tables stay invisible from the WordPress admin, but keep taking up space and sometimes slow down certain site-wide queries.

In the most extreme cases, an oversized or corrupted database can even trigger a database connection error. Regular cleaning remains the best prevention against this kind of incident.

Cleaning your database without risk

Before doing anything, one rule applies: never clean a database without a full backup beforehand. Once that precaution is taken, the process itself stays accessible:

  • use a recognised cleaning plugin rather than a manual SQL command if you are not comfortable with the database
  • delete revisions beyond a reasonable count (2 to 5 per post is usually enough)
  • empty spam and trashed comments
  • clean up expired transients
  • identify and remove tables left by plugins that are no longer installed

Optimising the tables after cleaning

Cleaning removes the unnecessary data, but MySQL tables often keep the freed-up space in a fragmented state. A table optimisation command (the equivalent of OPTIMIZE TABLE, offered by most cleaning plugins) physically reorganises this data and brings the database back to its real size. This step, often forgotten, is what delivers the real, measurable speed gain.

A lighter database responds faster to every query, which makes a direct difference if your WordPress site tends to slow down over the months.

When to call in a professional

Database cleaning touches the core of the site: its content, its settings, its memory. An overly broad deletion, a poorly targeted SQL command, or an optimisation launched without a backup can erase data that cannot be recovered. If your database exceeds several hundred megabytes, if the site stays slow despite a first cleanup, or if direct SQL work is required, it is safer to hand the operation to someone who does this regularly.

Frequently asked questions

Will cleaning the database slow my site down while it runs? On a high-traffic site, it is best to run it during off-peak hours, since optimising tables can briefly lock some of them. For most sites, the impact stays unnoticeable to visitors.

How often should the database be cleaned? A cleanup every three to six months is enough for most sites. A very active site, with lots of content and comments, can benefit from doing it monthly.

Does database cleaning replace caching? No, these are two complementary levers. Cleaning reduces the database's weight, while caching avoids querying it on every visit. Combined, the two give the best speed results.

Does your WordPress site seem to be slowing down for no obvious reason? Relax by Yumea diagnoses your database and hosting for free and gives you a clear solution, no jargon. Request my free diagnosis at /en/relax/site-wordpress-lent/