Skip to main content
WordPress accumulates a lot of housekeeping data: post revisions, expired transients, comment spam, autoloaded options. AccelerateWP’s database section sweeps it. The Heartbeat section throttles WordPress’s polling API, which can be a hidden CPU drain on busy admin pages.

​
Database cleanup

The Database group has individual toggles for each cleanup type, plus a button to run them on demand and a schedule for automatic cleanup.
ToggleWhat it removes
Post Cleanup → RevisionsPost and page revisions. WordPress saves a revision on every save by default. On a long-running blog, this is the biggest single source of database bloat.
Post Cleanup → Auto DraftsWordPress’s auto-saved drafts (the ones it creates if you start typing in a new post).
Post Cleanup → Trashed PostsPosts you’ve moved to trash but haven’t permanently deleted.
Comments Cleanup → Spam CommentsSpam-flagged comments that are sitting in the spam queue.
Comments Cleanup → Trashed CommentsTrashed (but not deleted) comments.
Transients Cleanup → Expired TransientsPlugin-set transient values that have passed their TTL.
Transients Cleanup → All TransientsEvery transient, including unexpired ones. Some plugins use long-lived transients to cache expensive computations, so wiping all transients can cause a temporary slowdown until the cache rebuilds.
Database Cleanup → Optimize TablesRuns OPTIMIZE TABLE on every WordPress table. Reclaims disk space from MySQL after the deletes.
Database cleanup is irreversible. There’s no “undo” once you remove revisions or trashed posts. Take an Export of the database before the first run, especially if any of the data above might be wanted later.

​
Run cleanup now or schedule

OptionWhat it does
Save Changes & OptimizeRuns every enabled cleanup type immediately.
Automatic cleanupRuns the same cleanup on a schedule. Frequencies: daily, weekly, monthly.
Daily is overkill for most sites. Weekly is a sensible default.

​
What you’d realistically gain

A typical WordPress install with ~500 posts and 6 months of activity:
TypeApprox rowsApprox MB
Post revisions5,000–10,00030–80 MB
Expired transients1,000–5,0005–25 MB
Trashed posts50–2001–5 MB
Spam commentsvaries wildly0–50 MB
Bigger sites (e-commerce, news) can have gigabytes in revisions alone. Cleanup can shave 30–60% off the database size.

​
Heartbeat control

The WordPress Heartbeat API polls the server every 15 seconds when an admin page is open. It powers post auto-saving, “user is editing this post” locks, and a few plugin features. On busy admin sessions it’s a non-trivial CPU drain. The Heartbeat section has three independent throttles:
SettingDefaultRecommendation
Backend (every admin page)60 secondsReduce to 120s or disable. Saves CPU when many users have admin tabs open.
Post editor15 secondsKeep enabled. This drives the auto-save you actually want.
Frontend (when a logged-in user views a public page)60 secondsDisable. Most plugins don’t need it on the front end.
Disabling Heartbeat can break plugins that rely on it (advanced editorial workflows, real-time analytics dashboards). If a feature stops working after a Heartbeat change, re-enable that scope first to confirm.

​
MAx Cache add-on

If your server has the Apache MAx Cache module installed, an extra add-on appears under Settings → Add-Ons. Toggling it on writes Apache directives into your site’s .htaccess so cached pages are served at the Apache level, faster still than the file-cache layer AccelerateWP uses by default. Requirements (visible if MAx Cache is available):
  • AccelerateWP version 3.20.0.3-1.1-33 or higher.
  • Apache MAx Cache module enabled on the server.
If the toggle isn’t visible, the server doesn’t expose MAx Cache. Open a ticket to ask whether your node has it.

​
Settings export and import

Bottom of the AccelerateWP page:
  • Export settings downloads a JSON file of every toggle, exclusion list, and schedule.
  • Import settings uploads a previously-exported file and restores the configuration.
Worth doing before:
  • WordPress major version updates.
  • Switching between PHP versions.
  • Migrating to another host (settings carry across cleanly).

​
Common issues

Almost always All Transients wiped a long-lived cache that a plugin (popular: SEO plugins, related posts) built up over weeks. The cache rebuilds on next request, but the request that triggers the rebuild is slow. Run Expired Transients instead of All Transients.
MyISAM and InnoDB don’t return space to the OS automatically. The rows are deleted but the file size is the same. Run Optimize Tables to reclaim. On InnoDB you may need a per-database OPTIMIZE via phpMyAdmin → Operations.
You disabled the post editor scope. Re-enable it. The auto-save you actually want is in this scope, not the global one.
AccelerateWP scheduling depends on WP-Cron. If your site is low traffic and WP-Cron only fires when someone visits, schedules can be missed. Either traffic the site to fire WP-Cron, or set up a server-side cron via Cron Jobs Manager to hit wp-cron.php reliably.

​
Need a hand?