Database Best Practices for WordPress

In addition to the issues we’ve explained in our general Database Best Practices guidelines, WordPress has a few database patterns that cause recurring problems on busy sites. Understanding them helps you avoid common pitfalls.

The wp_options Table

The wp_options table stores site configuration, plugin settings, and temporary data. It’s one of the most heavily used tables in WordPress—and one of the most frequently abused.

Autoload Bloat

Every row in wp_options has an autoload column. When set to yes, WordPress loads that option into memory on every single page request, whether it’s needed or not.

This is fine for small configuration values. But some plugins store large datasets with autoload enabled—we’ve seen plugins store thousands of items in a single autoloaded option. The result is megabytes of data loaded into memory on every request, slowing down the entire site. It also creates enormous traffic and server load for our databases, which can cause knock-on effects for other customers sharing the same database cluster.

It’s recommended to keep your total autoloaded data below 800 KB (kilobytes) for optimal performance.

To find your biggest autoloaded options, run:

SELECT option_name, LENGTH(option_value) AS size
FROM wp_options
WHERE autoload = 'yes'
ORDER BY size DESC
LIMIT 20;

If you find large entries, check whether the plugin has a setting to disable autoloading, or consider whether you can replace the plugin or do without it.

Serialized Arrays Growing Unbounded

Many plugins store data as serialized PHP arrays in a single option. Over time, these arrays can grow without limit—logging every event, queuing tasks, or accumulating analytics data.

Because it’s just one row, standard table size monitoring won’t flag it. You only notice when the site slows down or runs out of memory.

Transients That Never Expire

WordPress transients are meant to be temporary cached values. But some plugins use them as permanent storage, or set expiration times so far in the future that they effectively never expire.

Expired transients also aren’t cleaned up automatically unless you have an object cache configured. On sites without Redis or Memcached, the wp_options table fills up with stale transient data.

Object Cache Bypass

Even on sites with Redis or Memcached available, some plugins bypass the object cache and query wp_options directly. This defeats the purpose of having a caching layer and puts unnecessary load on the database.

Other WordPress Tables to Watch

Beyond wp_options, keep an eye on these tables:

  • wp_posts: WordPress stores every revision of every post. On content-heavy sites with frequent edits, revisions can outnumber actual posts by 10:1 or more. Consider limiting revisions in wp-config.php with define('WP_POST_REVISIONS', 5);
  • wp_postmeta: When posts are deleted, their meta entries often stay behind as orphans. Periodic cleanup queries can reclaim significant space.
  • wp_comments: Spam comments accumulate even with filtering plugins. Make sure you’re purging spam and trash regularly, not just marking them.