{
  "schema_version": 2,
  "id": "operate/rs/databases/memory-performance/eviction-policy",
  "title": "Eviction policy",
  "url": "https://redis.io/docs/latest/operate/rs/8.0/databases/memory-performance/eviction-policy/",
  "summary": "The eviction policy determines what happens when a database reaches its memory limit.",
  "content": "\nThe eviction policy determines what happens when a database reaches its memory limit.  \n\nTo make room for new data, older data is _evicted_ (removed) according to the selected policy. To prevent this from happening, make sure your database is large enough to hold all keys.\n\nIn clustered databases, each shard tracks its own memory usage and triggers eviction when it reaches its memory limit. If data is distributed unevenly across shards, some shards can fill up and start evicting keys while the overall database memory utilization is still below the configured limit.\n\n| **Eviction\u0026nbsp;Policy** | **Description** |\n|------------|-----------------|\n|  noeviction | New values aren't saved when memory limit is reached\u003cbr/\u003e\u003cbr/\u003eWhen a database uses replication, this applies to the primary database |\n|  allkeys-lru | Keeps most recently used keys; removes least recently used (LRU) keys |\n|  allkeys-lrm | Keeps most recently modifed keys; removes least recently modified (LRM) keys |\n|  allkeys-lfu | Keeps frequently used keys; removes least frequently used (LFU) keys |\n|  allkeys-random | Randomly removes keys |\n|  volatile-lru | Removes least recently used keys with `expire` field set to true |\n|  volatile-lrm | Removes least recently modified keys with `expire` field set to true |\n|  volatile-lfu | Removes least frequently used keys with `expire` field set to true |\n|  volatile-random | Randomly removes keys with `expire` field set to true |\n|  volatile-ttl | Removes keys with `expire` field set to true and the shortest remaining time-to-live (TTL) value |\n\n## Eviction policy defaults\n\n`volatile-lru` is the default eviction policy for most databases.\n\nThe default policy for [Active-Active databases](https://redis.io/docs/latest/operate/rs/databases/active-active) is _noeviction_ policy.\n\n## Active-Active database eviction\n\nThe eviction policy mechanism for Active-Active databases starts earlier than for standalone databases because it requires propagation to all participating clusters. The eviction policy starts to evict keys when a shard in one of the Active-Active instances reaches 80% of its memory limit.\n\n- The 80% threshold applies to each shard's memory limit, not to the overall database limit.\n\n- If memory usage continues to rise while keys are being evicted, the eviction rate increases to avoid out-of-memory errors.\n\n- To avoid over eviction, internal heuristics might prevent keys from being evicted when the shard reaches the 80% memory limit. In such cases, keys will be evicted only when shard memory reaches 100%.\n\n- Redis Software sometimes allocates a higher `maxmemory` value to individual shards to accommodate uneven key distribution and avoid out-of-memory errors.\n\nIn case of network issues between Active-Active instances, memory can be freed only when all instances are in sync. If there is no communication between participating clusters, it can result in eviction of all keys and the instance reaching an out-of-memory state.\n\n\u003e [!NOTE]\n\u003e Data eviction policies are not supported for Active-Active databases with Auto Tiering.\n\n## Avoid data eviction\n\nTo avoid data eviction, make sure your database is large enough to hold required values.  \n\nFor larger databases, consider using [Redis Flex or Auto Tiering ](https://redis.io/docs/latest/operate/rs/databases/flash).\n\nAuto Tiering stores actively-used data (also known as _hot data_) in RAM and the remaining data in flash memory (SSD).\nThis lets you retain more data while ensuring the fastest access to the most critical data.\n",
  "tags": ["docs","operate","rs","kubernetes"],
  "last_updated": "2026-10-21T09:46:20-07:00"
}