Clear WordPress Revisions and Spam on a Schedule Before the Database Bloat Shows Up
Your homepage can look fast in a lab test and still feel sticky in admin. Publish takes longer. Search in the post list stalls. The culprit is often not the theme and not the CDN. It is years of post revisions, auto-drafts, trashed posts, spam comments, orphaned meta, and expired transients sitting in MySQL like unused attic junk.
Visitors never see that table growth directly. They feel it as slower TTFB, heavier admin-ajax, and a site that “used to be snappy.” Core Web Vitals care about what the browser paints, but a bloated database still feeds every page build. If PHP and MySQL grind through dead rows before HTML starts, you are paying for garbage you already decided not to keep.
This post is about WordPress scheduled database cleanup inside Lightify: count first, approve a number, sweep revisions and spam on a schedule, then optimise the tables. Not delay JavaScript, not cache preload, not speculative loading, not YouTube facades, not self-hosting third-party assets, not the Core Web Vitals dashboard. Those are separate Lightify jobs. For why field speed still matters after a green lab score, see Core Web Vitals explained and how to fix LCP, CLS, and INP on WordPress in 2026.
The problem: quiet bloat that never makes the changelog
WordPress is polite about history. Every save can leave a revision. Auto-drafts linger. Trash sits for days or forever if nobody empties it. Akismet (or no spam filter at all) can leave thousands of spam comments in the table even after you “delete” them in the UI. Plugins write transients that expire in value but not always in storage. Meta rows orphan when posts disappear.
None of that ships as a red banner. There is no core alert for “48,000 revision rows and a 1.4 GB wp_posts table.” You notice when the editor feels late, bulk actions time out, backups take forever, queries scan noise, or hosting charts show rising DB size with flat traffic.
Teams often throw another caching plugin at the symptom. Full-page cache helps the front end. It does not shrink wp_posts, wp_postmeta, wp_comments, or wp_options clutter. You can warm the cache perfectly and still drag a fat database behind every miss. Pair cleanup with full-page caching and cache preload when you are ready. Start by removing what should not be there.
What Lightify actually ships for database cleanup
Stick to real product behaviour. No invented “AI vacuum” claims.
Scheduled cleanup of revisions, spam, and transients. Lightify clears the junk on a schedule instead of waiting for a yearly “DB doctor” panic.
Revisions, drafts, trash, spam, and stale transients. The sweep targets post revisions, auto-drafts, trashed content, spam comments, orphaned meta, and expired transients.
Optimises tables once the sweep is done. After rows are gone, Lightify optimises the tables so MySQL can reclaim space.
Counted first, so you approve a number not a promise. Before anything is deleted, you see counts. You approve a concrete total, not a vague cleanup promise.
Scheduled weekly (for example at 3am). Product copy uses weekly at 3am as the example window: low traffic, predictable, out of the way of daytime editors.
That is the feature. Count, approve, schedule, sweep, optimise. Repeat without opening phpMyAdmin.
Adjacent bloat cleanup (same family, not the main job)
Database rows are one half of WordPress bloat. The other half is requests and scripts that ship on every page whether you use them or not. Lightify’s cleanup family also covers disabling emojis, dashicons, jQuery Migrate, and oEmbed when you do not need them, throttling Heartbeat, and switching off XML-RPC when you are not using remote publishing.
Treat those as companion switches. They cut request noise. They do not replace scheduled database cleanup. Turn them on when they match your stack, then come back to the revision and spam schedule that is the point of this post.
How to run the first counted sweep
Treat Database Cleanup like a product checklist, not a developer dump into production at lunch.
Take a backup first. Snapshotify (same Pro membership) or your host backup. Junk is still data until you are sure.
Open Lightify’s database cleanup UI. Check counted items: revisions, drafts, trash, spam, stale transients, related meta. Read the numbers before anything irreversible.
Approve the count you are willing to remove. If a number looks wrong (for example, drafts you still need), adjust what is included. You approve a number, not a promise.
Run an initial sweep if the backlog is huge. A five-year content site may need one big pass before the weekly schedule only maintains a thin layer.
Let table optimisation finish. After the delete, Lightify optimises the tables. Give that step room. Do not stack a migration on top of it.
Turn on the weekly schedule. Weekly at 3am (the product example) is a sane default for most brochure and content sites. Weekly is the shipped framing.
Confirm admin and front still behave. Spot-check a few posts, comments, and a search. Confirm spam is gone and intentional drafts you kept are still there.
What belongs in the sweep (and what does not)
Safe and intended for this feature:
- Old post revisions you do not need for legal or editorial history
- Auto-drafts that never became posts
- Trash that has already sat past your recovery window
- Spam comments and their noise
- Expired transients that plugins forgot to delete
- Orphaned meta left behind after content was removed
Think twice before treating everything as disposable: revisions on legal or regulated content where history matters, trash younger than your team’s recovery window, and transients some plugins misuse as durable storage (rare, but real). If a plugin documents “do not purge our options/transients,” respect that and keep the schedule focused on the WordPress junk classes Lightify lists.
If you keep 50 revisions per post “just in case,” you are choosing disk and query cost. Most marketing sites need a handful at most, then a scheduled wipe of the rest.
Pitfalls that make cleanup look scary or useless
Skipping the count. Blind “optimize database” plugins that delete without a preview are why people fear cleanup. Lightify shows counts first. Use that.
Running two cleanup plugins. WP-Optimize, Advanced Database Cleaner, and similar tools overlapping the same tables can race. Pick one owner for this job.
Expecting front-end LCP to jump from DB cleanup alone. Cleanup removes ballast. It helps generation cost, admin feel, and backup size. Hero images, third-party scripts, and cache misses still dominate CWV. Fix those in their own Lightify sections.
Cleaning once and never scheduling. Bloat returns every save and every spam wave. The product is scheduled cleanup, not a one-off ritual.
No backup before the first big purge. Always, especially on agency client sites.
Blaming cleanup when the host is already near storage limits. Cleanup helps. It is not a substitute for upgrading a starved plan after years of media uploads.
How this fits DaftPlug Pro
Lightify is one of five Pro plugins on a single membership. One licence unlocks Progressify (PWA), Lightify (performance), Generatify (AI), Rankify (SEO and GEO), and Snapshotify (backups). Plans differ by site count only: Pro $37.99/year (1 site), Pro Plus $74.99 (5), Pro Max $138.99 (100). Features are identical across plans. Checkout is Freemius, with a 14-day money-back guarantee. See pricing.
Free Lightify on WordPress.org covers a serious slice of performance. Scheduled database cleanup with counted approval, weekly runs, and table optimisation is why sites with years of editorial churn move to Pro instead of stacking a separate “DB cleaner” renewal.
Takeaway
WordPress does not warn you when revisions, spam, trash, orphaned meta, and expired transients turn the database into a slow attic. Lightify counts what it will remove, you approve the number, then it sweeps on a schedule (weekly at 3am in the product example) and optimises the tables afterward. Pair that with the adjacent bloat switches when they fit, keep a backup before the first big pass, and leave caching and CWV work to their own settings. Stop paying query tax on junk you already decided not to keep.
