> ## Documentation Index
> Fetch the complete documentation index at: https://help.noxity.io/llms.txt
> Use this file to discover all available pages before exploring further.
# Database and Heartbeat
> Clean up bloated WordPress database tables, throttle the Heartbeat API, and use the MAx Cache add-on if your server has it.
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.
| Toggle | What it removes |
| ------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Post Cleanup → Revisions** | Post 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 Drafts** | WordPress's auto-saved drafts (the ones it creates if you start typing in a new post). |
| **Post Cleanup → Trashed Posts** | Posts you've moved to trash but haven't permanently deleted. |
| **Comments Cleanup → Spam Comments** | Spam-flagged comments that are sitting in the spam queue. |
| **Comments Cleanup → Trashed Comments** | Trashed (but not deleted) comments. |
| **Transients Cleanup → Expired Transients** | Plugin-set transient values that have passed their TTL. |
| **Transients Cleanup → All Transients** | Every 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 Tables** | Runs `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](/web-hosting/cpanel/database-management/phpmyadmin/export) of the database before the first run, especially if any of the data above might be wanted later.
### Run cleanup now or schedule
| Option | What it does |
| --------------------------- | ------------------------------------------------------------------------- |
| **Save Changes & Optimize** | Runs every enabled cleanup type immediately. |
| **Automatic cleanup** | Runs 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:
| Type | Approx rows | Approx MB |
| ------------------ | ------------- | --------- |
| Post revisions | 5,000–10,000 | 30–80 MB |
| Expired transients | 1,000–5,000 | 5–25 MB |
| Trashed posts | 50–200 | 1–5 MB |
| Spam comments | varies wildly | 0–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:
| Setting | Default | Recommendation |
| -------------------------------------------------------- | ---------- | ------------------------------------------------------------------------------ |
| **Backend** (every admin page) | 60 seconds | Reduce to **120s** or disable. Saves CPU when many users have admin tabs open. |
| **Post editor** | 15 seconds | **Keep enabled.** This drives the auto-save you actually want. |
| **Frontend** (when a logged-in user views a public page) | 60 seconds | Disable. 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](/web-hosting/cpanel/database-management/phpmyadmin/table-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](/web-hosting/cpanel/advanced-settings) to hit `wp-cron.php` reliably.
## Need a hand?
Best for anything that needs an account check or a config change on our end.
Faster for quick questions during business hours.