Clean Up the Database

Removes rows WordPress accumulates and never removes on its own. Everything lives on the Database tab: a manual run you can start at any time, and a scheduled run that is off by default. Both work in the background with live progress, so the admin screen never waits for them.

Tasks

Task	Label	Deletes
revisions	Post revisions	Revision posts. A scheduled run and wp gt-performance database run keep the newest revisions of each post (see retention); a manual run from the admin, and database run --all-revisions, delete every revision.
auto_drafts	Auto-drafts	Posts with the auto-draft status
spam_comments	Spam comments	Comments marked spam, permanently
trashed_posts	Trashed posts	Posts, pages and other post types in the Trash, permanently
trashed_comments	Trashed comments	Comments in the Trash, permanently
expired_transients	Expired transients	Transients past their expiry, through WordPress’s delete_expired_transients()
all_transients	All transients	Every _transient_* and _site_transient_* row in the options table, including active ones, then flushes the object cache. Manual runs only.
optimize_tables	Database tables	Runs OPTIMIZE TABLE on each table with your WordPress table prefix that reports reclaimable space (InnoDB, MyISAM or Aria)

Posts and comments are deleted through wp_delete_post() and wp_delete_comment(), so WordPress’s own delete hooks run and their metadata goes with them. See Cleaner.

All transients also removes what GT Performance keeps in transients: reusable unused-CSS builds (each page queues a new build on its next uncached visit) and minified JavaScript (tags fall back to the original script until it is minified again). With a persistent object cache such as Redis, the flush empties that cache too.

These deletions are permanent. Back up the database before deleting content or clearing all transients.

Running a cleanup now

Manual database optimization lists every task with its current count. The saved scheduled tasks are preselected; All transients never is. Select what you want and press Run selected optimization.

The button returns at once. The run is saved and worked through by the background queue in short slices: up to 100 posts or comments per slice, or one table. See CleanupRun.

• Live progress. While the Database tab is open it checks the run every few seconds, and each check also advances it by about four seconds of work, so progress does not wait for the next queue tick. Each task shows its count so far and whether it is done, working, waiting or not run.
• Stop. Stop after this batch ends the run once the current slice finishes. Tasks not reached show not run.
• Leaving the page. The run keeps going in the background queue.
• One at a time. A new run cannot start while one is active.
• Abandoned runs. A run nothing has advanced for 30 minutes is shown as Latest run stopped making progress, and a new run can start. Check the background queue on Tools.
• Priority. Manual runs are queued ahead of cache warming and preloads but behind purges. Scheduled runs wait behind warming and preloads too.

The result stays on the tab afterwards: Latest run finished, Latest run was stopped or Latest run failed (with the error), marked as a Manual or Scheduled run.

Cleanup does not purge your pages

Deleting revisions, auto-drafts, trashed posts, spam comments or trashed comments leaves the page cache alone. Trashing a post already purged its pages, and spam or trashed comments were never on a public page, so emptying the trash or deleting spam changes nothing a visitor sees. Deleting a published post directly, without trashing it first, still purges its pages. See Purging.

Scheduled cleanup

The Scheduled database optimization panel:

Setting	Key	Default
Schedule database cleanup	database.enabled	off
Cleanup schedule	database.schedule	weekly (daily, weekly, monthly)
Scheduled revisions to retain	database.retain_revisions	5 (0 to 100)
Scheduled tasks	database.tasks	every task except All transients, which is not available on a schedule

• The first scheduled run happens one hour after the settings are saved. Changing the schedule reschedules the event; turning it off clears it. The WP-Cron hook is gt_performance_database_cleanup.
• A scheduled run is the same background run as the manual button and shows its progress on the tab the same way. It is skipped when another run is still active.
• Retention counts per post: with 5, the five most recently modified revisions of every post are kept and the rest are deleted.

WP-CLI

wp gt-performance database                        # preview: counts for every task, deletes nothing
wp gt-performance database run                    # run the saved scheduled tasks now
wp gt-performance database run --all-revisions    # same, but delete every revision

The preview counts every revision and every transient, not only what a scheduled run would remove. Look at the counts before enabling anything on a site whose editorial history you care about.

run works through the saved Scheduled tasks to completion in the current process, in batches of 1,000. It does not use the background queue. If Post revisions is among the saved tasks, it keeps the newest Scheduled revisions to retain of each post, as a scheduled run does, so a server cron calling it behaves like the built-in schedule. Add --all-revisions to delete every revision, as the admin’s Run selected optimization does. See WP-CLI.

Keeping revisions down

GT Performance does not cap how many revisions WordPress keeps. Set WordPress’s WP_POST_REVISIONS constant in wp-config.php for that. A longer Autosave interval on Optimization > Editor, comments, and APIs reduces autosave churn; see Media, Fonts and Embeds.