WordPress database maintenance: keeping your migrated site lean and fast

The part of your site nobody sees slowing down

After a migration everyone looks at the design and the page speed score, but the database quietly grows in the background. Every post revision, every expired temporary option, every plugin you tested and removed leaves rows behind. A year later the site that felt snappy at launch hesitates on every page, and the owner assumes they need more expensive hosting. Often they just need maintenance.

The database is the heart of WordPress: posts, pages, settings, users and plugin data all live there. Keeping it lean is not glamorous work, but it is the difference between a site that ages well and one that gets sluggish for no visible reason.

Revisions: the biggest silent growth

By default WordPress saves every version of every post forever. A page edited fifty times stores fifty full copies. On a content-heavy site that is the single largest source of bloat I encounter. Limit revisions to a sensible number, five is plenty, with one line in the configuration file, and clean the existing mountain of old revisions once.

Two related items: the trash, which keeps deleted posts and comments for thirty days, and spam comments, which pile up faster than you expect. Empty both regularly. None of this is risky as long as you have a backup first, which brings me to the golden rule below.

Safe cleaning without breaking things

The golden rule of database work: backup first, always, no exceptions. A full, tested backup takes one bad afternoon and turns it into a ten-minute restore. Only then touch the database.

For cleaning I use a reputable optimisation plugin rather than hand-written queries, because the good ones know which tables are safe to touch. The routine targets: old revisions, trashed and spam comments, expired transients (temporary cached values that plugins forget to delete), and orphaned data from removed plugins. That last category is the sneaky one: many plugins leave their tables and settings behind on uninstall. Twice a year, review the table list for names of plugins you no longer use, and remove the leftovers after confirming they belong to something truly gone.

Finding the queries that actually hurt

If the site is slow despite a clean database, the next step is measuring instead of guessing. A query monitor plugin shows exactly which database queries each page runs and how long they take. In my audits the culprit is usually one of three things: a plugin that queries on every page load something it should cache, a search or archive page that scans tens of thousands of rows, or autoloaded options, settings loaded on every request, that have grown to megabytes because some plugin stored logs in them.

Fixing those is developer work, but identifying them is not. Even a screenshot of the slow query list gives a developer everything needed to fix it in an hour instead of billing you for a day of investigation.

A maintenance calendar that actually happens

Maintenance fails when it depends on remembering. Put it in the calendar: monthly, empty trash and spam, check the backup ran, glance at the error log. Quarterly, run the optimisation plugin and review autoloaded options. Twice a year, audit leftover plugin tables and review user accounts. If a partner like Convert2WP converted your site, ask what maintenance routine they recommend for your specific setup, because a site with a shop needs a tighter schedule than a brochure site.