You compressed the images. You cut the plugin list down. Caching is working. The site is still slower than it should be, and you have run out of obvious things to check.
Look at the database. It is the one part of a WordPress site nobody ever sees, which is exactly why it gets into a state.
What is actually in there
Your database holds every post, page, setting, user, comment and plugin option on the site. It also holds a large amount of material you never asked for.
- Post revisions. WordPress saves a full copy of a post every time you save it, forever, by default. Edit a page thirty times and you have thirty complete copies. On a content-heavy site, revisions can outnumber real posts several times over.
- Auto-drafts and trashed posts. Start a post, abandon it, and it stays. Delete a page and it sits in trash indefinitely unless something clears it.
- Spam and unapproved comments. A site with comments open can accumulate thousands of spam entries that nobody ever empties.
- Orphaned metadata. When you delete a post or a plugin, the extra data attached to it often stays behind, referencing something that no longer exists.
- Expired transients. Temporary cached values that are supposed to clean themselves up and frequently do not.
- Tables from plugins you removed. Many plugins create their own tables and leave them behind on uninstall. Statistics plugins are the worst for this and can leave hundreds of megabytes.
Why any of this makes pages slower
Every uncached page load asks the database questions. The bigger and messier the tables, the longer each answer takes.
Two things make it worse than raw size suggests. First, databases store data in indexes, and heavily churned tables develop the equivalent of fragmentation, so the same query has more ground to cover. Second, some plugins run queries that scan whole tables rather than using an index, and those get dramatically slower as the table grows.
It also hits you where you feel it most: the admin panel. A slow WordPress dashboard, a post list that takes ten seconds to load, a media library that hangs. That is usually a database problem rather than a front-end one.
The other cost: your backups
A bloated database makes every backup bigger and slower to run, and every restore slower to complete. When you actually need to restore, after a bad update or a security incident, the size of the thing you are restoring turns directly into minutes of downtime.
You are also paying storage for years of post revisions and spam comments you would never want back.
What safe cleanup looks like
The routine work is not complicated, but the order matters and so does the backup.
- Take a full backup first. Not negotiable. Database cleanup is one of the few maintenance jobs that can lose real content if done carelessly.
- Remove old post revisions, keeping a small number of recent ones per post rather than deleting all of them.
- Clear auto-drafts and empty the trash for posts and comments.
- Delete spam and unapproved comments.
- Remove orphaned post and comment metadata.
- Clear expired transients.
- Remove pingbacks and trackbacks if you do not use them.
- Optimize the tables afterwards, which is what reclaims the space and tidies the indexes.
The fix: also cap revisions going forward so the problem does not immediately rebuild. Keeping the last few revisions per post is plenty for practical purposes and stops the table growing without limit.
The part to be careful about
Leftover tables from deleted plugins are tempting to remove and are where people cause damage. Table names are not always obvious, and deleting the wrong one takes live content with it. If you are not certain what a table belongs to, leave it alone until someone who is certain looks at it.
The same caution applies to any tool offering to "clean" your database with one aggressive button. Aggressive defaults sometimes delete all revisions including the one you needed, or clear data a plugin depends on. This is work that should be done deliberately, on a schedule, with a backup already in place.
Why this never gets done
Database maintenance has no trigger. Nothing breaks visibly. No warning appears. There is no notification badge in WordPress telling you there are 6,000 revisions in there. So it waits until the site is slow enough that someone finally goes looking, by which point there is years of it.
It is the definition of work that only happens if it is scheduled by somebody whose job it is.
Put it on a schedule and forget it
Database cleanup and cache purging are part of routine maintenance on every Up Speed plan, alongside scheduled off-site backups with one-click restore, tested updates and 24/7 uptime monitoring. The backup runs before the cleanup, which is the right order and the reason it is safe to run regularly.
You do not get a control panel to learn or a checklist to work through. It happens, and it shows up in a plain-English monthly report. That starts at the Starter plan.