WordPress object cache: Persistent vs. Non-Persistent Storage Explained

Last month, I spent about two days debugging a site that felt sluggish despite having a "caching plugin" installed. The database CPU was spiking, yet the site looked like it was configured correctly. It turned out the developer assumed the default wp_cache was doing the heavy lifting, not realizing that WordPress’s default object caching is non-persistent and vanishes the moment the page load finishes.

Understanding how the WordPress object cache works is the difference between a site that handles traffic and one that falls over at the first sign of a spike. If you’re building anything more complex than a static blog, you need to know how these bits of data live and die.

What is the WordPress Object Cache?

At its core, the wp_cache API is a way to store data in memory during a single page request. When you query the database for a complex list of posts or a set of user settings, WordPress can store that result in memory. Subsequent calls to the same data during that same request don't hit the database again; they pull from RAM.

This is incredibly fast, often reducing retrieval time by a few milliseconds. However, it’s limited. By default, WordPress uses a "non-persistent" object cache. This means that once the PHP process finishes executing and sends the response to the user, that cache is flushed. It’s gone. If another user hits the site a millisecond later, WordPress performs the exact same database queries from scratch.

Persistent vs. Non-Persistent Storage

The distinction here is simple: persistence.

• Non-Persistent: Data lives only for the duration of a single request. It’s stored in a PHP variable or a local memory buffer. It’s useful for preventing redundant queries within one request (like fetching the same meta value five times in a single loop), but it does nothing for the next visitor.
• Persistent: Data is stored in an external service like Redis or Memcached. When a user requests a page, the data is pulled from that external store. If the data isn't there, it's fetched from the database, saved to the cache, and then served. This persists across different requests and different users.

If you are looking to scale, you should check out my WordPress Performance: Implementing Redis Persistent Object Caching guide to see how we move beyond the default limitations.

When to use the Transient API

You might have heard of the Transient API. It’s a wrapper around the object cache that includes an expiration time. If you’re storing something that doesn't need to be perfectly real-time—like a social media feed or an aggregated list of products—transients are your best friend.

Here is a basic example of how I use them to cache an expensive query result:

PHP
$data = get_transient('my_expensive_data');

if (false === $data) {
    #6A9955">// The cache expired or doesn't exist, hit the database
    $data = $wpdb->get_results("SELECT * FROM complex_table");
    
    #6A9955">// Store it for 12 hours
    set_transient('my_expensive_data', $data, 12 * HOUR_IN_SECONDS);
}

#6A9955">// Now use $data

The beauty of the Transient API is that it’s "persistence-aware." If you have a persistent object cache (like Redis) configured, WordPress will automatically store your transient in that persistent layer. If you don't, it falls back to the wp_options table in your database. This is a crucial point for WordPress performance—storing transients in the database is better than nothing, but it still incurs a disk I/O cost.

Why the Default Setup Often Fails

We’ve seen developers try to solve site slowness by just installing a plugin, but that’s rarely enough. If you’re interested in the deeper mechanics, WordPress object caching optimization: A guide for senior engineers breaks down how to avoid common pitfalls like cache stampedes.

I once worked on a project where we used a custom caching layer for an API integration. We initially tried to store the responses in a standard wp_cache group. It broke because, under high load, the cache key collisions were rampant. We switched to a namespaced approach using wp_cache_add with unique groups, which fixed the data integrity issues immediately.

Frequently Asked Questions

Does the object cache replace the need for page caching? No. Page caching (saving the HTML output of a page) is for the entire request. The object cache is for specific data objects (like database results) used to build that page. They work best together.

How do I know if my site is using a persistent object cache? You can check the wp-content directory for an object-cache.php file. If it exists, you are likely using a persistent drop-in. If it’s missing, you’re on the default non-persistent system.

Is it safe to cache everything? Absolutely not. Caching is a trade-off. If you cache data that changes frequently, you’ll end up serving stale content. Always consider the "Time to Live" (TTL) carefully.

I’m still experimenting with how to best handle cache invalidation for complex custom post types—sometimes, the simplest delete_transient calls aren't enough when you have deeply nested relationships. Caching is never a "set it and forget it" task; it’s an iterative process of measuring and refining.