{"id":74574,"date":"2026-06-12T02:09:06","date_gmt":"2026-06-12T08:09:06","guid":{"rendered":"https:\/\/www.scalahosting.com\/blog\/?p=74574"},"modified":"2026-06-12T02:09:08","modified_gmt":"2026-06-12T08:09:08","slug":"redis-eviction-policies","status":"publish","type":"post","link":"https:\/\/www.scalahosting.com\/blog\/redis-eviction-policies\/","title":{"rendered":"Redis Eviction Policies: Which One to Use"},"content":{"rendered":"\n

Your Redis<\/strong><\/a> cache fills up. It always does – that’s the point of a memory limit. What happens in the next millisecond is decided by a single setting most people accept the default for and never look at again.<\/p>\n\n\n\n

The eviction policy.<\/p>\n\n\n\n

Get it right, and Redis quietly protects your busiest data, keeps your hit rate high, and makes your site feel fast under load. Get it wrong, and Redis may evict useful keys or reject writes, depending on the policy. In SPanel, the policy is exposed as a dropdown instead of a manual redis.conf edit. <\/p>\n\n\n\n

The performance gap is real – a Deloitte study found that a 0.1-second improvement in mobile site speed lifted retail conversion rates by 8.4%<\/a>.<\/p>\n\n\n\n

So let’s clear up what a Redis eviction policy actually does, walk through all eight of them in plain language, and land on the one you should probably use.<\/p>\n\n\n\n

SPanel<\/strong><\/a> users can change the Redis eviction policy from the Redis Cache screen instead of editing. Simply go to the Redis Cache Manager,<\/strong> and you will see a Mempolicy <\/strong>dropdown on the left side.<\/p>\n\n\n\n

What Is a Redis Eviction Policy?<\/strong><\/strong><\/h2>\n\n\n\n
\"Redis<\/figure>\n\n\n\n

A Redis eviction policy is the rule Redis follows to decide which keys to delete when its memory limit is reached and a new write needs room. It answers one question: when the cache is full, what gets thrown out to make space?<\/p>\n\n\n\n

Two things have to be true before eviction ever happens:<\/p>\n\n\n\n

    \n
  1. A memory ceiling exists.<\/strong> Redis only evicts when it hits the limit set by its maxmemory value<\/a>. With no limit, Redis keeps consuming RAM until the operating system steps in – which is its own kind of problem.<\/li>\n\n\n\n
  2. A new write needs space.<\/strong> Eviction is triggered by demand. Redis frees room reactively, key by key, as writes come in and memory is already full.<\/li>\n<\/ol>\n\n\n\n

    Here’s the part that trips people up. <\/p>\n\n\n\n

    Out of the box, open-source Redis ships with noeviction as its default policy, which means it evicts nothing<\/em> and starts rejecting writes once memory fills. That’s a safe default for a database, but a poor one for a cache. (More on why in a moment – and it’s a big reason managed environments override it.)<\/p>\n\n\n\n

    Volatile vs. Allkeys: The First Fork in the Road<\/strong><\/h3>\n\n\n\n

    Before the eight Redis eviction policies make sense, you need one distinction. Every policy operates over one of two scopes:<\/p>\n\n\n\n