WordPress Database Optimization: Revisions, Transients, Autoload and Cleanup

Every WordPress page view reads from the database. Over the years, a site collects post revisions, expired temporary data, leftover settings from deleted plugins and oversized options that load on every request. None of this breaks the site, but some of it can slow down page generation and the admin, especially on busy sites and stores.

Database optimization means removing what is not needed, stopping it from piling up again, and making sure the data you do need can be read efficiently. The parts that usually matter most are autoloaded options, transients, revisions and slow queries from specific plugins. Running "optimize tables" on its own rarely changes much.

A word on expectations: how much faster a cleanup makes your site depends entirely on what is in your database and how your hosting is set up. Some sites see a clear improvement in admin and uncached page speed; others see none, because the bottleneck was never the database. Measure before and after rather than trusting any promised percentage.

This guide explains each type of clutter, the tools that clean it, the role of indexes and object caching, and when the job needs a developer.

How the WordPress database is organized

A standard WordPress install uses a set of core tables. The ones that matter most for performance:

• wp_posts: posts, pages, revisions, menu items, attachments and custom post types, including WooCommerce products.
• wp_postmeta: extra fields attached to posts. Plugins and page builders store a lot here, and this table is often the largest.
• wp_options: site settings and plugin settings, plus transients when no object cache is in use.
• wp_comments, wp_users, wp_usermeta, wp_terms and related tables.

Plugins often add their own tables. WooCommerce, for example, stores orders in dedicated tables when High-Performance Order Storage is enabled, which has been the default for new stores since WooCommerce 8.2. Form, analytics, security and logging plugins frequently create tables too, and some keep them after you uninstall the plugin.

Post revisions

Every time you update a post, WordPress saves a revision so you can roll back. That is useful, but by default WordPress keeps revisions without a limit. On sites with long-lived pages edited hundreds of times, revisions can be a large share of wp_posts and their meta.

The fix is to set a limit in wp-config.php. According to the wp-config documentation, WP_POST_REVISIONS defaults to true (keep all), can be set to false to disable revisions, or to a number such as 5 to keep that many per post. A small number keeps the safety net without the bloat. Disabling revisions entirely is rarely a good idea on content sites.

Related settings: autosaves happen every 60 seconds by default (AUTOSAVE_INTERVAL), and trashed items are permanently deleted after 30 days (EMPTY_TRASH_DAYS).

Setting a limit does not remove existing revisions. Use a cleanup tool once to trim old ones, then let the limit stop the growth.

Transients

Transients are temporary cached values with an expiry time, such as an API response or a computed list. Without a persistent object cache, they are stored in wp_options.

Two facts from the Transients API documentation matter here. First, expiry is a maximum, not a guarantee; a transient may disappear early. Second, WordPress cleans out expired transients only infrequently, so on sites where plugins create many uniquely named transients, expired ones can build up.

Deleting expired transients is safe: WordPress or the plugin will regenerate them when needed. Developers can run wp transient delete --expired with WP-CLI. Deleting all transients is also generally safe, but it can cause a brief slowdown while caches rebuild.

If transients grow back quickly by the thousands, find out which plugin creates them. That is a plugin issue, not a one-time cleanup job.

Autoloaded options

This is often the most important item on the list. Options marked for autoloading are loaded into memory on every single request, front end and admin, whether the page needs them or not. If plugins store large values with autoload on, every request pays for it.

WordPress 6.6 made several changes, described on Make WordPress Core:

• A Site Health check that reports a critical issue when the total size of autoloaded options exceeds 800 KB.
• Options larger than 150 KB are no longer autoloaded automatically unless a developer explicitly asks for it.
• New autoload values in the database (on, off, auto, auto-on, auto-off). Existing yes and no values were not migrated and are treated as on and off.

To check your site, go to Tools > Site Health. If the autoloaded options check fails, find the largest autoloaded options. A developer can query wp_options for the biggest values, or use a cleanup plugin that lists them. Common culprits are leftover settings from deleted plugins, logs stored as options, and large cached data saved by themes or page builders.

Fixing it means deleting options that belong to plugins you no longer use, or switching autoload off for large options that are rarely needed. Be careful: switching off autoload for an option a plugin needs on every request just moves the cost to a separate query. If you are not sure who owns an option, ask a developer before deleting it.

Other clutter worth cleaning

Cleanup tools

This is a neutral list of well-known tools, not a ranking. Install bands are from WordPress.org as of October 2026.

When choosing a cleanup plugin, check when it was last updated, whether it is tested with your WordPress version, whether it shows exactly what it will delete before deleting, and whether you can run it once and then remove it. A cleanup plugin does not need to stay active forever. Our post on WordPress database plugins covers custom data storage from a development angle.

Optimizing tables

MySQL and MariaDB tables can hold unused space after many deletions. wp db optimize runs the mysqlcheck utility with its optimize option, and many cleanup plugins have an "optimize tables" button. This can reclaim disk space after a big cleanup. On modern InnoDB tables the speed gain is usually small, and optimizing a large table can lock it while it runs, so do it in a quiet period and after a backup.

Indexes and slow queries

Indexes let the database find rows without scanning a whole table. WordPress core tables come with indexes for common lookups. In wp_postmeta, for example, the core schema indexes post_id and meta_key, but not meta_value. That is why plugins or themes that search or sort by meta values on large sites can generate slow queries.

Finding slow queries is a developer task:

• Query Monitor shows the queries each page runs, which component ran them, and how long they took.
• Your host's slow query log shows the worst offenders over time.
• Fixes range from changing how a plugin queries data, to adding a carefully chosen index, to storing data in a custom table designed for the job.

Adding indexes to core tables is possible but should be done by someone who understands the trade-offs: indexes speed up reads, slow down writes and take space, and plugin updates or migrations need to account for them.

Object caching: often the bigger win

The official WordPress optimization documentation explains that a persistent object cache, such as Redis or Memcached, saves trips to the database by keeping query results in memory between requests. With one in place, options and transients load faster, and transients are stored in the cache instead of wp_options. Site Health also recommends a persistent object cache when it detects a site that would benefit.

Many managed hosts offer Redis or Memcached as an option. For stores, membership sites and busy blogs, object caching combined with page caching usually matters more than any cleanup. See our WordPress speed and performance guide for the wider picture.

A safe database maintenance routine

1. Back up the database and confirm the backup works. See our WordPress backups guide.
2. Measure first: note the database size, Site Health results and a few page timings, especially uncached and admin pages.
3. Run the cleanup on staging first for large or complex sites, using a staging copy.
4. Clean the safe categories: expired transients, old revisions, spam and trash, orphaned meta.
5. Review autoloaded options and leftover tables, deleting only what you can attribute to a removed plugin.
6. Set limits so clutter does not return: revision limits and log retention in plugin settings.
7. Measure again and keep notes.

For most sites, a light cleanup every few months is plenty.

When to involve a developer

• Site Health reports large autoloaded options and you cannot tell which plugin owns them.
• The database is very large, or specific pages, searches or admin screens are slow even with caching.
• A store has slow checkout or order screens, or you are moving to WooCommerce's HPOS tables.
• Query Monitor shows slow queries coming from a theme, a page builder or custom code.
• You are considering adding indexes or custom tables.

Conclusion

WordPress database optimization is less about clicking "optimize" and more about controlling what loads on every request. Back up first, clean the safe categories, keep autoloaded options lean, limit revisions, and add a persistent object cache on busy sites. Measure before and after so you know what helped. For more guides, see our WordPress hub. eSEOspace also handles database and performance work through its site speed optimization service.

Frequently asked questions