WordPress revisions fill your database faster than you think

16 July 2026

The espresso machine hisses in the corner of your co-working desk, condensation forming on the window as morning traffic hums three floors below, and somewhere in a data centre your WordPress database is growing by another fifty kilobytes you’ll never need.

WordPress saves every keystroke as a database row—here’s when that becomes a problem

Default revision settings create thousands of orphaned rows that slow queries and bloat backups.

WordPress newsletter plugin custom templates interface with import options

WordPress writes a new revision record every time you click save or step away from the editor for sixty seconds. If you’re running a site with five hundred published posts and you edited each one three times before hitting publish, your database now holds at least fifteen hundred revision rows—none of which appear on your front end, and most of which you’ll never restore.

The real cost shows up in three places: backup file size (every revision gets exported), query performance (WordPress has to filter revisions out of post queries), and hosting limits (shared plans cap database size at 1–2 GB). A site with a thousand posts and loose revision hygiene can easily carry 5,000+ revision rows, adding 40–60 MB to your database and 15–20 seconds to a full backup export.

The fix is a single line in wp-config.php: define('WP_POST_REVISIONS', 3); caps stored revisions at three per post. For existing sites, a manual purge via WP-CLI (wp post delete $(wp post list --post_type='revision' --format=ids)) or a plugin like WP-Optimize clears the backlog. If you publish daily and edit in public view, five revisions is a safer ceiling; if you draft long-form and rarely restore old versions, two is enough.

Run SELECT COUNT(*) FROM wp_posts WHERE post_type = 'revision'; in phpMyAdmin to see your current count. If the number is higher than three times your published post count, you’re carrying dead weight.

Read the full story

TACTIC

When your affiliate links stop converting, check the cookie window first

Most affiliate programmes default to 30-day tracking cookies, but your evergreen content continues driving clicks for six, twelve, eighteen months after publication. If a reader bookmarks your guide in January and buys in March, you earn nothing—the cookie expired weeks earlier. The mismatch is structural: long-tail SEO content has a lifespan measured in years, whilst attribution windows close in weeks. You can’t extend the cookie unilaterally, but you can shift content strategy to favour shorter purchase cycles or negotiate longer windows with direct partners before you invest in content that won’t pay out.

See the breakdown

WORTH WATCHING

Zapier deletes task history after two weeks—archive or lose it

Zapier’s task log retention is shorter than most operators expect: fourteen days on all plans, including paid tiers. After that, the record of what fired, what failed, and what data passed through each step vanishes permanently. If you’re troubleshooting a workflow that broke three weeks ago, you’re reconstructing from memory. The fix is proactive: route task metadata to a Google Sheet, Airtable base, or AWS S3 bucket as part of every high-stakes Zap. It adds one step and costs near-zero, but it preserves the audit trail you’ll need when a client asks why their invoice didn’t send or a lead didn’t sync.

Read more

FROM THE ARCHIVE

Image optimisation plugins clash when you stack lazy load and CDN rewrites

Most WordPress operators run a lazy-load plugin and a CDN rewrite plugin side by side, assuming they’ll cooperate. In practice, execution order matters: if the CDN plugin rewrites image URLs before the lazy-load library parses the DOM, you’ll serve full-resolution images on first paint and defeat the point of lazy loading. If lazy load fires first and the CDN plugin can’t find the original src attribute, images break entirely. The conflict is silent until you audit with Lighthouse or WebPageTest and notice that above-the-fold images are either missing or unoptimised. The solution is to choose one plugin that handles both jobs—or manually sequence their hooks in functions.php.

See how to stack them

Know someone who would like this? Forward today’s email — every operator we reach is one closer to running an online business with a little less friction.