Database Cleaner
Why the WordPress wp_postmeta Table Gets So Large
Find what is driving wp_postmeta growth, identify the plugins and features behind large meta keys, and remove only data proven to be obsolete.
Main Menu
A WordPress database grows in ways nobody chooses. Every saved draft leaves a revision, every plugin leaves options, every spam comment stays until something removes it, and expired temporary data often is not. A site with two hundred posts can carry a database of hundreds of thousands of rows, most of which nothing reads.
Size alone is not the problem — slow queries are. These guides start with finding out where the weight actually is, because the answer differs by site and guessing wastes effort. Usually it is post metadata, sometimes it is autoloaded options being read on every single page load, and on stores it is often a scheduler table nobody knew existed.
Then the cleanup itself, one category at a time: old revisions, expired transients, spam and trashed comments, metadata whose parent post no longer exists. Each article covers what is safe to remove and what looks disposable but is not.
There is also table optimisation, which reclaims space the database has marked free but not returned, and a short piece on how often any of this is worth doing.
One article here is not optional reading: the one on backing up first. Database cleanup is the one maintenance task with no undo, and a delete with a wrong condition is indistinguishable from data loss. Take the export, then run the query.
Find what is driving wp_postmeta growth, identify the plugins and features behind large meta keys, and remove only data proven to be obsolete.
Determine whether a WordPress database cleanup is still running before retrying it, then fix the actual timeout, lock or batch-size problem.
Set WordPress database cleanup intervals from measured growth, retention rules and recovery readiness instead of a universal weekly schedule.
Create a fresh, complete and restorable WordPress database backup before deleting rows or running any cleanup operation.
Reduce large Action Scheduler tables without deleting pending WooCommerce work or hiding the failed jobs that explain a backlog.
Find and remove WordPress metadata only after proving its parent object is gone and excluding active migrations or custom ownership rules.
Audit WordPress autoloaded options by total size, ownership and request impact before changing or deleting configuration data.
Find which WordPress tables and data owners are driving database growth before deleting revisions, logs or plugin records.
Optimize WordPress database tables only after checking the engine, fragmentation, free space, locking cost and recovery path.
Delete old spam and trashed WordPress comments without losing false-positive reviews, abuse evidence or required retention records.