Database Health: the safe cleanup workflow

PowerSEC's Database Health screen (in the plugin under Database → Database Health, and on the Central dashboard under your site's Database Health panel) shows a health score, a per-table breakdown, and a set of one-click cleanup actions. This guide explains what those numbers mean and the safe order in which to act on them, so you tidy your database without risking your content.

What "overhead" is — and why a small number is fine

Overhead is reported per table from MySQL's Data_free value. It represents space the storage engine has set aside inside the table's data file but is not currently using for live rows.

On modern WordPress installs almost every table uses the InnoDB engine, and for InnoDB this free space is mostly normal and not reclaimable to the operating system. InnoDB keeps free pages inside its tablespace and reuses them automatically as you add and delete data. Running OPTIMIZE TABLE on InnoDB does not zero out that number — it rebuilds the table and the free space typically reappears shortly after.

Because of this, PowerSEC deliberately does not treat a low overhead figure as a problem:

• The per-table view only flags a table when overhead is large in absolute terms (roughly 50 MB+ for InnoDB tables, 10 MB+ for others).
• The header "Optimization recommended" nudge only appears when total overhead is meaningful (about 20 MB+).
• The health score is only penalised when overhead is large both in bytes and as a share of total size.

Takeaway: a few KB or a handful of MB of overhead is expected and healthy. Do not chase it to zero.

The authoritative signal is the health score and AI advisor — not the raw overhead number

Look at the health score (0–100) and its state — healthy (80+), needs_attention (60–79), or at_risk (under 60) — together with the AI advisor summary shown above the table. These weigh everything that actually matters: expired transients, post revisions, spam/trash comments, orphaned postmeta, oversized autoload options, and runaway log/analytics tables — not just overhead.

If the advisor says you're healthy, you're healthy, even if a table shows some overhead. Act on the advisor's recommendations rather than reacting to a single raw metric.

The safe cleanup workflow

Follow this order. The single most important step is the first one.

1. Back up the database first. Always create (or confirm) a recent backup before any cleanup. Cleanup deletes rows, and a backup is your undo button. PowerSEC enforces this for you: its cleanup guardrails will warn if a backup is running and block higher-impact cleanups when there is no recent backup (or the latest one is too old). Use the plugin's backup feature, then proceed.
2. Optimize tables. Use Optimize now (or the per-table Optimize). This defragments tables and is low risk. Remember it will not zero InnoDB overhead — that's expected.
3. Clear expired transients. Transients are cached temporary data in wp_options. Clearing the expired ones only removes data WordPress would have regenerated anyway. Safe.
4. Trim old post revisions. WordPress keeps a copy of every edit. Trimming revisions older than your configured window removes editing history but never your current published content. Low risk; the current version of each post is untouched.
5. Empty trash. Permanently deletes posts/comments already in Trash past your retention window. Safe, but it is permanent — confirm Trash holds nothing you still want.
6. Delete spam comments. Removes comments already marked spam. Safe.

After cleanup, refresh the panel and confirm the health score and advisor summary improve. Re-check the overhead expectation above before worrying about any remaining number.

Safe vs. needs-care at a glance

Safe (low risk): optimize tables, clear expired transients, trim old revisions, delete spam comments. These only touch regenerable, already-discarded, or historical data.

Needs care (permanent deletions): emptying trash and any action that removes content past a retention cutoff. They don't touch live content, but they are irreversible — which is exactly why step 1 is to back up first.

PowerSEC protects your live data structurally: core content tables (wp_posts, wp_options, wp_users, wp_comments, wp_terms, and their meta/relationship tables) are never offered as "empty" targets. Cleanup is limited to a fixed, audited set of actions — optimize, expired transients, old revisions, auto-drafts, spam/trash comments, orphaned postmeta, and known append-only log/analytics tables — so you cannot accidentally wipe your site from this screen.

Using "Optimize now" and per-table Optimize

• Optimize now (the button in the page header, available on every tab) runs a one-time pass: it optimizes your tables and, per your saved Optimization settings, clears expired transients and trims old revisions/spam/trash. It reports back how many of each it touched.
• Per-table Optimize lets you optimize a single table from the table list — handy when the advisor calls out one specific table.

You can run these manually at any time. For the deletion-style cleanups, the backup guardrails described above still apply.

Pro: scheduled auto-optimize

On paid plans PowerSEC can run this cleanup for you on a schedule. Under Database → Optimization you can enable auto-optimize, choose a frequency (e.g. weekly), and set what each run includes — expired transients, how many days of revisions to keep, and trash/spam handling. Set it once and your database stays tidy automatically, with the same safety guardrails as the manual run. On the free tier you can still optimize on demand with Optimize now; the scheduled automation and the granular cleanup actions are the paid add-on.

In short: read the health score and advisor, not the overhead number; back up before you delete anything; then optimize → clear expired transients → trim revisions → empty trash → delete spam, in that order. PowerSEC blocks the risky paths for you and never exposes your core content tables to deletion.