Eviction policies

An instance has a fixed amount of memory. The eviction policy answers one question: *when memory is full and a write arrives, what gives way?* This page explains each policy in the console's Eviction Policy dropdown and when to choose it.

Updated 13 Aug 20263 min read

An instance has a fixed amount of memory. The eviction policy answers one question: when memory is full and a write arrives, what gives way? This page explains each policy in the console's Eviction Policy dropdown and when to choose it.

The default follows the purpose

You rarely need to change this setting. The default comes from the instance's purpose and matches what each purpose is for:

Cache instances default to allkeys-lru — a full cache quietly drops the data least likely to be needed again, and every write succeeds.
Store instances default to noeviction — a full store refuses writes rather than silently deleting data you meant to keep.

The policy remains freely settable either way. The console warns when you pick a combination that is unusual for the purpose — valid, but worth a second look.

How to read the policy names

Every policy name answers two questions:

Which keys are candidates? allkeys- policies consider every key. volatile- policies only consider keys that have an expiry (TTL) set — keys without one are never evicted.
In what order? lru evicts the least recently used, lfu the least frequently used, random picks at random, and ttl evicts whatever is closest to expiring anyway.

The policies

Policy	Candidates	Evicts first	Choose it when
`noeviction`	—	Nothing — writes fail when full	Data must never be silently lost. Your application handles write errors, or memory is sized generously. The store default.
`allkeys-lru`	All keys	Least recently used	General-purpose caching. Recently touched entries stay; stale ones go. The cache default, and the right answer for most caches.
`volatile-lru`	Keys with a TTL	Least recently used	One instance holds both cache entries (with TTLs) and durable keys (without). Only the cache entries are ever evicted.
`allkeys-lfu`	All keys	Least frequently used	Access patterns with a stable hot set — popularity matters more than recency. A one-off batch scan cannot flush out your genuinely hot keys, which LRU would allow.
`volatile-lfu`	Keys with a TTL	Least frequently used	The mixed-content pattern of `volatile-lru`, with frequency ordering for a stable hot set.
`allkeys-random`	All keys	Random	Every key is equally likely to be requested again, so tracking usage buys nothing. Rare in practice.
`volatile-random`	Keys with a TTL	Random	Expiring keys are interchangeable and you only need to protect the non-expiring ones. Rare in practice.
`volatile-ttl`	Keys with a TTL	Shortest remaining TTL	Your TTLs already encode importance — evicting what would expire soonest anyway loses the least.

Two pitfalls to avoid

A volatile- policy with no TTLs set is noeviction in disguise. If nothing has an expiry, there are no candidates, and writes fail when memory fills. Only choose volatile- policies when your application reliably sets TTLs on the evictable keys.

noeviction on a cache moves the problem into your application. When the cache fills, writes start failing, and your code has to treat every cache write as fallible. If losing cold entries is acceptable — and for a cache it almost always is — allkeys-lru is the better contract.

LRU or LFU?

Both keep "important" keys; they define importance differently. LRU (recency) adapts fast when your hot set shifts, but a single large scan of cold keys can push genuinely hot keys out. LFU (frequency) resists that pollution and suits stable popularity distributions, but takes longer to recognise that yesterday's hot key has gone cold. Start with LRU; move to LFU if you observe scan traffic evicting keys you cared about.

Changing the policy

The eviction policy can be changed at any time from the console, the Reis CLI or Terraform (maxmemorypolicy). The change applies as a rolling update and affects future evictions only — nothing already stored is touched by the change itself.