WordPress's database grows in ways that have nothing to do with your actual content — post revisions, spam comments, expired transients, and orphaned metadata accumulate quietly for years. On an old, actively used site, it's common to find the majority of database rows are pure overhead. Here's what's actually worth cleaning, and what isn't.
The biggest sources of database bloat
- Post revisions. By default, WordPress saves a full revision every time you save a draft or update a published post — with no limit. A frequently edited page can accumulate dozens of revisions, each a near-duplicate copy of the content stored in
wp_posts. - Expired transients. Transients are meant to be temporary cached values with an expiration, but plugins don't always clean up after themselves reliably, especially if a site's cron stopped running for a period. Expired transients that were never purged just sit in
wp_optionsindefinitely. - Spam and unapproved comments. These accumulate in
wp_commentsand, if unmoderated for a long time, can genuinely number in the tens of thousands on a site that gets any comment-spam traffic. - Orphaned post meta. When a post is deleted directly via database operations (rare) or by certain plugins that don't clean up properly, its
wp_postmetarows can be left behind with no matching post. - Auto-drafts and trashed posts left indefinitely instead of being permanently deleted.
What to actually do about it
Limit post revisions going forward, rather than only cleaning up the backlog — add define('WP_POST_REVISIONS', 10); (or a number appropriate to your editing workflow) to wp-config.php. This caps future growth without needing repeated manual cleanup.
Clean up existing revisions and auto-drafts — either through a well-reviewed WP-CLI command (wp post delete for specific post types, or a maintenance plugin's cleanup tool) rather than raw SQL unless you're confident in the query. Always back up the database first; this is a destructive operation.
Purge expired transients specifically, not all transients — deleting active/valid transients just forces plugins to regenerate that cached data on the next request, which is wasted work, not a real cleanup win.
Empty spam and trashed comments on a schedule, not just once. WordPress's own comment moderation settings can auto-delete spam after a set number of days — configure that rather than relying on remembering to do it manually.
Check for orphaned postmeta and orphaned relationships using a well-tested cleanup tool, and always back up first — this is the one category where a bad automated cleanup can actually break site functionality if a plugin was relying on data that looked "orphaned" but wasn't.
What not to bother with
Don't obsess over shaving a few hundred KB of genuinely small tables, and don't run aggressive "optimize all tables" operations on a schedule without understanding what they do — OPTIMIZE TABLE on InnoDB tables briefly locks the table and rebuilds it, which is fine occasionally on a maintenance window but not something to run casually on a live high-traffic site.
Indexes matter more than row count for most sites
For sites with real query performance problems, the actual bottleneck is far more often a missing index on a custom query (from a theme or plugin) than raw table size — WordPress's core tables are already reasonably indexed for its own query patterns. If a specific page or admin screen is slow, profile the actual slow query (via SAVEQUERIES in a debug environment, or your host's slow query log) before assuming a database cleanup will fix it. Cleanup helps overall hygiene and backup size; it's not always the fix for a specific slow page.
The takeaway
Database maintenance on WordPress is mostly about capping ongoing growth (revision limits, comment auto-purge) and doing periodic, backed-up cleanup of what's already accumulated — not a one-time fix. Treat it as routine maintenance, and reach for real query profiling, not just cleanup, when you have an actual performance problem to solve.
