Database cleanup

What it does

A WordPress database collects things nobody asked to keep: dozens of saved revisions of every page, auto-drafts the editor creates each time it opens, trash and spam nobody emptied, data left behind by plugins and posts that are long gone, and cached values that expired months ago. None of it breaks the site on its own, but it makes backups bigger and slower, and some of it (old transients and orphaned data) slows queries down.

Database cleanup shows you what is there and removes it safely, on every plan. It runs through the WPClientHub One plugin on the site — version 0.10.0 or newer — and works the same on MySQL and MariaDB, whatever the table prefix.

• Analyze only reads. It counts each kind of removable data (with an estimated size), reads every table’s size and its free space, and shows the result on the site’s Database card. Nothing changes.
• Clean removes exactly the kinds you tick — nothing else — in small batches, and takes a restore point first when the site has backups.

What a cleanup removes

What it never touches

• Users and their data.
• WooCommerce orders — order posts (classic storage), refunds, subscriptions, order notes, and data that belongs to an order in WooCommerce’s newer order tables.
• Settings: the only rows removed from the options table are expired transients.
• Plugin tables: tables a plugin created are listed with their sizes, but never cleaned or optimized.
• Files: a trashed media item is left alone, because deleting it would also delete its file from the uploads folder.

How it stays safe

• A restore point first. When the site has backups set up (a backup schedule, or at least one completed backup), every cleanup — manual or scheduled — starts with a fresh full backup, labelled Before database cleanup in the site’s restore points, and waits for it to finish. If that backup fails, nothing is cleaned — unless you ticked Run without a restore point, in which case the cleanup runs and its result says that it ran without one.
• Sites without backups. WPClientHub does not start the first full backup on a client’s server on its own. On such a site a cleanup only runs when you tick Run without a restore point; the dialog says so plainly.
• WordPress does the deleting wherever it has a function for it — revisions, posts and comments go through WordPress’s own delete functions, so their metadata, comment and term counts, caches and other plugins’ hooks stay correct. Plain database queries are used only for rows whose parent is already gone (orphaned data) and for expired transients, the same statement WordPress runs for those every day.
• Small batches, a time budget. Rows are removed 500 at a time, and each call to the site stops after about 20 seconds; WPClientHub calls again until it is done. A big cleanup never runs into the host’s time limit or locks a table for long.
• Never alongside a backup or restore. The plugin refuses to clean while a backup or restore is running on the site; WPClientHub waits and carries on.

When tables are optimized

Deleting rows leaves free space inside a table. Whether optimizing gives that space back depends on the storage engine:

• MyISAM and Aria tables with any free space are optimized — that is where it helps most.
• InnoDB (the default for years) reuses the space for new rows on its own, and rebuilding a table copies all of it. So an InnoDB table is rebuilt only when the free space is real: at least 16 MB and a fifth of the table, with the table in its own file. In a shared tablespace a rebuild would give nothing back to the disk, so it is skipped.
• Tables bigger than 512 MB are never rebuilt from here, and only the WordPress tables the cleanup wrote to are ever considered.

That is why “— 48 MB smaller” appears only when the database really got smaller on disk; on an all-InnoDB site a cleanup often removes thousands of rows and the files stay the same size until the space is reused.

Where you see it

• The Database card on each site’s Overview tab: the database size, the free space in its tables, an estimate of what a cleanup removes, what each item counts right now, the largest tables, when it was last cleaned, the schedule, and Analyze / Clean now.
• The Activity Log (System category): one line per cleanup, for example “Database cleanup removed 1,240 revisions and 3,200 expired transients — 48 MB smaller”, with the before and after numbers attached. A cleanup that could not run says why.
• Client reports: one line in the Updates section — “The database was cleaned on 3 October 2026: 1,240 revisions and 3,200 expired transients removed — 48 MB smaller.”
• Restore points: the backup taken first appears in the Backups tab as Before database cleanup, and can be restored like any other.

How to

1. Open the site and find the Database card on the Overview tab. A site that has never been analyzed is analyzed the first time the card is opened.
2. Press Analyze for fresh numbers (once a minute per site). It only reads.
3. Press Clean now. Tick what to remove — the defaults are pre-ticked — and adjust how many revisions to keep per post and how old trash, spam and auto-drafts must be. Leave Optimize tables on unless you have a reason not to.
4. Choose Back up, then clean. The card shows the restore point being taken, then the cleanup’s progress, then the result. You can leave the page.
5. To clean on a schedule, press Set a schedule on the card: weekly (pick the day) or monthly (pick a day from the 1st to the 28th, so every month has it), the hour, and the timezone. Each run starts within about half an hour of that time — sites are spread out so they do not all run in the same minute — and takes its own restore point first.

Owners, Admins and Techs can analyze, clean and schedule. Viewers see the card but cannot change anything.

“Update WPClientHub One to use database cleanup”

A site whose WPClientHub One is older than 0.10.0 cannot clean its database, and the card says so instead of offering buttons that would fail. Owners and Admins get the usual Update the plugin button right there (the same update as the site’s plugin panel); a site on a plugin too old to update itself needs the new version installed by hand once. Once the site reports 0.10.0, its first analysis runs on its own.

Multisite

On a multisite network, the cleanup covers the site the plugin is connected through and only that site’s own tables — on the main site its wp_* tables without the other subsites’ wp_2_* ones or the network tables (users, network settings); on a subsite its wp_N_* tables. Network-wide transients are left to WordPress.

Limits & defaults

Troubleshooting