All about Redis

Redis is the in-memory store your site uses for caching, sessions and queues. If Redis is available to you, you already have one to connect to, and you can create extra ones when a project needs its own.

This article explains the difference between the one you already have and the extra ones, the per-instance settings, and the eviction policies, including which one to pick when in doubt.

The short version

Every cluster with a Redis-group node already has a main Redis instance. Configure it in 'Cluster Properties' > 'Redis'.
If you don't know which eviction policy to pick: allkeys-lru for a cache, noeviction for a queue or session store.
Don't run a cache and a queue on the same instance with allkeys-lru. Redis drops queue jobs to make room for cache entries, with no error. See Mixing caches and queues.

What Redis is

An in-memory NoSQL data store. Most projects use it as a cache (WordPress object cache, Laravel or Symfony cache backend) because reads and writes against memory are much faster than against MariaDB or PostgreSQL on disk.

It is not only a cache. The same instance can hold:

Session stores — server-side login sessions for PHP, Laravel, Symfony, Rails.
Queues — job backends for Laravel Horizon, Sidekiq, Bull, RQ.
Rate-limit counters and locks — atomic INCR and SETNX for throttling and one-at-a-time guards.
Pub/sub channels — fan-out messaging for real-time features.
Application data — leaderboards, recent-activity feeds, presence tracking. Redis is a full key/value store with lists, sets, sorted sets, hashes and streams.

Which of these an instance is for decides the eviction policy you want. A cache may drop keys without telling you — the next read just goes to the database. A queue or session store may not: a dropped key there is a lost job, or a user who gets signed out.

The main Redis instance

Ready to use as soon as the cluster has a Redis-group node. Two settings in 'Cluster Properties' > 'Redis':

'Redis Password' — minimum 24 alphanumeric characters.
'Redis Memory Limit' — memory cap in MB.

Additional Redis instances

To create one: the top-level 'Redis Instances' page > 'Create'.

Create one when you need:

A separate password for a specific app or tenant.
A dedicated memory budget that will not compete with other workloads.
A different eviction policy than the main instance uses.

Otherwise the main instance is enough.

Fields

'Cluster' — must have a Redis-group node.
'Name' — lowercase, digits, dash, underscore.
'Port' — the TCP port the instance listens on.
'Password' — minimum 24 alphanumeric characters.
'Memory Limit (MB)' — minimum 8.

'Max Databases' sets how many Redis logical databases the instance exposes (the indices you SELECT between). 'Eviction Policy' is below.

Eviction policies

When an instance hits its 'Memory Limit (MB)', the eviction policy decides what happens to the next write.

Two questions:

What is evictable? All keys, only keys with a TTL (a time-to-live set with EXPIRE), or nothing.
Which key goes first? Least-recently used (LRU), least-frequently used (LFU), shortest TTL, or random.

If you're not sure: allkeys-lru

For a WordPress object cache, or a Laravel or Symfony cache backend, pick allkeys-lru. It treats the whole instance as a cache, evicting keys that have not been touched in a while as new ones come in — whether or not you set TTLs on what you write.

Same advice for WooCommerce, Craft, a Magento page cache, and Symfony's cache pool.

The eight policies

Policy	What's evictable	How it chooses	When to pick
`noeviction`	nothing	writes fail with an error	Queues, session stores, anything where losing a key is worse than rejecting a write
`allkeys-lru`	all keys	Least Recently Used	The default for caches. WordPress, Laravel cache, generic page cache
`allkeys-lfu`	all keys	Least Frequently Used	Caches with a clear hot/cold split where recency lies, for example when a periodic crawler touches everything once
`allkeys-random`	all keys	random	Rarely right. Only when access patterns are perfectly uniform
`volatile-lru`	only keys with a TTL	Least Recently Used	Mixed instance: cache entries get TTLs, app data doesn't, and only the cache should evict
`volatile-lfu`	only keys with a TTL	Least Frequently Used	Same as `volatile-lru`, for hot/cold-by-frequency patterns
`volatile-random`	only keys with a TTL	random	Rarely right
`volatile-ttl`	only keys with a TTL	shortest TTL first	When the keys closest to expiring anyway should go first

The four allkeys-* policies evict anything when the instance fills up. Right when the whole instance is a cache, dangerous when it also holds things you cannot afford to lose.

The four volatile-* policies only touch keys with an explicit TTL. A key written without EXPIRE is untouchable. Right when one instance holds both cache entries (with TTLs) and durable application data (without).

noeviction: when the instance is full, writes fail with an out-of-memory error. Reads still work. Right for queues and session stores, where an error the application can retry beats dropping a job or signing a user out.

Mixing caches and queues on one instance

A cache and a queue on the same instance with allkeys-lru: the instance fills up, Redis evicts queue jobs to make room for fresh cache entries, and jobs are dropped with no error.

Either split into two instances, or set noeviction and size the memory limit for the queue's worst case.

How instances are typically split

One site's cache backend — the main instance is almost always enough. A dedicated instance is not worth the extra password management.
One instance per tenant or environment — one tenant's heavy cache writes cannot push another tenant's entries out. Use noeviction when the instance is the queue backend.
Separate instances per role — one tuned for cache (allkeys-lru, generous memory), one for queues (noeviction, smaller memory).
A dedicated instance for a storefront's session and cart store, isolated from analytics or BI workloads on the same cluster.