PHP forgets everything at the end of each request. That keeps servers stable, but it also means you rebuild the same data over and over, like routing tables or lists pulled from a database. This RFC from Go Kudo adds a new bundled extension, user_cache, that keeps values in memory so later requests can reuse them.

Why add it

Today you have two main options, and both have limits. OPcache preloading only handles scalars and arrays of scalars. APCu has to serialize objects on the way in and unserialize them on the way out. The RFC wants a cache that can hold objects without paying that cost every time.

How you use it

Here is the RFC's basic example:

use UserCache\Cache;

$cache = Cache::getPool('default');

// store() overwrites an existing entry; add() fails if the key exists.
$cache->store('routes', $routingTable, 3600);

$routes = $cache->fetch('routes');

The TTL is in seconds, and 0 means the entry never expires.

The Cache class also has:

  • add(), has(), delete() and clear()
  • storeMultiple(), fetchMultiple() and deleteMultiple()
  • increment() and decrement() for counters
  • remember(), which returns the cached value or runs your callback and stores the result
  • lock() and unlock(), so one worker can rebuild a value while the others wait

Pools keep entries separate, so one pool never sees another pool's keys.

How it stores values

The extension picks the fastest way to store each value. Scalars and plain arrays are copied straight into shared memory, and most objects are stored in a form that doesn't need serialization. Objects with __unserialize() or __wakeup() still have those methods called, and anything else falls back to full serialization.

If the cache is disabled, the methods still exist and behave as if every lookup is a miss, so libraries can call them without checking first.

Each server setup keeps its own cache. In php-fpm, each worker pool gets one, and in Apache, each virtual host does. The CLI has it disabled by default.

What it means for existing code

The UserCache namespace and the user_cache.* ini settings become reserved, so code or extensions already using those names would clash. Nothing else changes.

Where it stands

The RFC is under discussion. It was first posted on July 19, 2026, targets PHP 8.7 (or 8.6), and follows an earlier "OPcache Static Cache" RFC by the same author. The locking rules are still an open question. The page has a vote set up, but no one has voted yet.