WordPress database optimization for revisions and transients means deleting old revision rows and expired cache rows. Post revisions are full copies of posts saved on each update, and transients are temporary cached values stored in the database. Large blogs and shops feel the bloat first. Small sites can cap growth now and avoid heavy tables later.
Table of Contents
- How revisions fill wp_posts
- How to cap future revisions
- Where transients live and why autoload matters
- How to clean transients without breaking cache
How revisions fill wp_posts
WordPress.org Documentation states in its revision guide that WordPress saves a revision for each draft save or published update by default with no limit. A post edited 40 times keeps 40 rows in wp_posts unless capped.
CKTechCheck notes each revision lives as its own full row with post_type equals revision. Site owners can audit with SELECT COUNT(*) FROM wp_posts WHERE post_type equals revision, then bulk-delete old rows.
How to cap future revisions
Developer.WordPress.org explains in its wp-config reference that owners limit future revisions with define wp_post_revisions in wp-config.php. Setting the value to 3 keeps three revisions plus one autosave per user.
Use these values: Set the cap before editing grows the table. Existing revisions stay until deleted separately.
- true or -1 keeps every revision
- 0 or false keeps only one autosave
- positive integer keeps that many plus one autosave per user
Where transients live and why autoload matters
Developer.WordPress.org WP-CLI notes transients persist in wp_options without a persistent object cache, or in wp_sitemeta on multisite. With a Redis or Memcached drop-in they skip the database and wrap the object cache.
Developer.WordPress.org notes transients with an expiration are not autoloaded by default. Transients with no expiration use 0 and autoload, so they load on every page and can add per-request memory cost.
How to clean transients without breaking cache
Developer.WordPress.org WP-CLI states in its transient command reference that wp transient delete minus minus expired removes only rows past timeout. Using minus minus all forces all cached values to regenerate on next load.
Veravix reports every autoloaded wp_options row loads in one query at the start of every request. Since WordPress 6.6 Site Health flags autoloaded options over 800 KB as critical. Developer.WordPress.org and DCHost note core delete_expired_transients does nothing with external object cache, so test database deletes on staging with a backup.
