Why Your WordPress Database Gets Huge, and How to Shrink It Safely?
We recently cut a client's WordPress database from 1,043 MB to 113.9 MB, an 89% reduction, on a live site that never went down. Almost none of what we removed was content the business needed. Here is where that weight comes from.
What is actually filling your database
Post revisions
WordPress saves a complete copy of a post every time you save a draft. Edit a long page twenty times and you have twenty full copies. Multiply across every page and post, over years, and revisions alone can dominate the database.
Expired transients
Transients are cached values with an expiry date. The catch is that expiring does not mean deleting: expired transients often sit in the options table indefinitely. Plugins that cache aggressively can leave behind tens of thousands of rows nobody will ever read again.
Autoloaded options
Some options are loaded on every single page request, whether needed or not. A bloated options table is uniquely damaging because you pay for it on every visit, not just occasionally. On the site above, the options table held nearly 2,000 entries.
Orphaned metadata
Delete a post and its metadata does not always go with it. Over time you accumulate rows describing content that no longer exists.
Plugin leftovers
The big one. Uninstalling a plugin usually removes its files, not its tables. Analytics, page builders, backup tools and form plugins all create their own tables, and most leave them behind forever. A site that has trialled a dozen plugins can carry a dozen abandoned tables. The site above had 107 tables against a WordPress core that ships with 12.
Why it matters beyond disk space
Slower queries. Every page load searches larger tables.
Backups that fail. Large databases push past hosting timeouts, and a backup that times out is not a backup.
Hosting limits. Many shared plans cap storage. Hitting the cap can block backups, updates, and eventually writes.
Slower recovery. When something breaks, restoring a gigabyte takes far longer than restoring a hundred megabytes, and that is time your site is down.
How to check yours
In your hosting control panel, open phpMyAdmin and select your WordPress database. The list of tables shows the size of each one. Two things to look for:
Any single table far larger than the rest, particularly
wp_options,wp_postmetaorwp_posts.Tables whose prefix you do not recognise, which usually belong to plugins you no longer run.
Anything over a few hundred megabytes on a normal business site is worth investigating.
Cleaning it without breaking anything
Back up first, and verify the backup restores. An untested backup is a guess. This is not optional, and it is the step people skip.
Do not delete a table because you do not recognise it. The prefix rarely matches the plugin name, and some tables belong to something still in use. Identify before deleting.
Work in stages, checking between each. Clear revisions, check the site. Clear transients, check again. If something breaks you know exactly which step caused it and how to reverse it. A single sweeping cleanup gives you no such information.
Be careful with one-click optimiser plugins. They are fine for revisions and transients. They are not judgement, and they cannot tell whether an unfamiliar table is abandoned or load-bearing.
When to bring someone in
Do it yourself if you only need revisions and transients cleared and you have a verified backup. Get help if your database is over a gigabyte, if you are near a hosting limit, if backups are failing, or if the site earns money and downtime is not acceptable.
That last one is the real dividing line. The risk is not the cleanup, it is doing it on a live site with real customer data and no way back.
The result to aim for
On the project above, the database went from 1,043 MB to 113.9 MB with the site live and taking bookings throughout. Another client's database came down to roughly a quarter of its original size, in their words "without a single issue affecting the website".
Neither involved deleting anything the business needed. That is the point: most of what fills a WordPress database is not your content.
If your database has grown past the point where you are comfortable touching it, get in touch and we will tell you what is in there before anyone changes anything.
DesignDotIT
Written by the DesignDotIT team, building web applications, AI agents, and automations for businesses around the world.
Need a web application built right?
Customer portals, internal dashboards, or a full rebuild, scoped properly and quoted with a fixed price before any work starts.