{
  "id": "memory-performance",
  "title": "Memory and performance",
  "url": "https://redis.io/docs/latest/operate/rs/7.8/databases/memory-performance/",
  "summary": "Learn more about managing your memory and optimizing performance for your database.",
  "content": "Redis Enterprise Software has multiple mechanisms in its\narchitecture to help optimize storage and performance.\n\n## Memory limits\n\nDatabase memory limits define the maximum size your database can reach across all database replicas and [shards]() on the cluster. Your memory limit will also determine the number of shards you'll need.\n\nBesides your dataset, the memory limit must also account for replication, Active-Active overhead, and module overhead, and a number of other factors. These can significantly increase your database size, sometimes increasing it by four times or more.\n\nFor more information on memory limits, see [Database memory limits]().\n\n## Eviction policies\n\nWhen a database exceeds its memory limit, eviction policies determine which data is removed. The eviction policy removes keys based on frequency of use, how recently used, randomly, expiration date, or a combination of these factors. The policy can also be set to `noeviction` to return a memory limit error when trying to insert more data.\n\nThe default eviction policy for databases is `volatile-lru` which evicts the least recently used keys out of all keys with the `expire` field set. The default for Active-Active databases is `noeviction`.\n\nFor more information, see [eviction policies]().\n\n## Database persistence\n\nBoth RAM memory and flash memory are at risk of data loss if a server or process fails. Persisting your data to disk helps protect it against loss in those situations. You can configure persistence at the time of database creation, or by editing the database’s configuration.\n\nThere are two main types of persistence strategies in Redis Enterprise Software: append-only files (AoF) and snapshots.\n\nAppend-only files (AoF) keep a record of data changes and writes each change to the end of a file, allowing you to recover the dataset by replaying the writes in the append-only log.\n\nSnapshots capture all the data as it exists in one moment in time and writes it to disk, allowing you to recover the entire dataset as it existed at that moment in time.\n\nFor more info on data persistence see [Database persistence with Redis Enterprise Software]() or [Durable Redis](https://redis.com/redis-enterprise/technology/durable-redis/).\n\n## Auto Tiering \n\nBy default, Redis Enterprise Software stores your data entirely in [RAM](https://en.wikipedia.org/wiki/Random-access_memory) for improved performance. The [Auto Tiering]() feature enables your data to span both RAM and [SSD](https://en.wikipedia.org/wiki/Solid-state_drive) storage ([flash memory](https://en.wikipedia.org/wiki/Flash_memory)). Keys are always stored in RAM, but Auto Tiering manages the location of their values. Frequently used (hot) values are stored on RAM, but infrequently used (warm) values are moved to flash memory. This saves on expensive RAM space, which give you comparable performance at a lower cost for large datasets.\n\nFor more info, see [Auto Tiering]().\n\n## Shard placement\n\nThe location of the primary and replica shards on the cluster nodes can impact your database performance.\nPrimary shards and their corresponding replica shards are always placed on separate nodes for data resiliency and high availability.\nThe shard placement policy helps to maintain optimal performance and resiliency.\n\nRedis Enterprise Software has two shard placement policies available:\n\n- **dense**: puts as many shards as possible on the smallest number of nodes\n- **sparse**: spread the shards across as many nodes as possible\n\nFor more info about the shard placement policy, see [Shard placement policy]()\n\n## Metrics\n\nFrom the Redis Enterprise Software Cluster Manager UI, you can monitor the performance of your clusters, nodes, databases, and shards with real-time metrics. You can also enable alerts for node, cluster, or database events such as high memory usage or throughput.\n\nWith the Redis Enterprise Software API, you can also integrate Redis Enterprise metrics into other monitoring environments, such as Prometheus.\n\nFor more info about monitoring with Redis Enterprise Software, see [Monitoring with metrics and alerts](), and [Memory statistics]().\n\n## Scaling databases\n\nEach Redis Enterprise cluster can contain multiple databases. In Redis,\ndatabases represent data that belong to a single application, tenant, or\nmicroservice. Redis Enterprise is built to scale to 100s of databases\nper cluster to provide flexible and efficient multi-tenancy models.\n\nEach database can contain few or many Redis shards. Sharding is\ntransparent to Redis applications. Master shards in the database process\ndata operations for a given subset of keys. The number of shards per\ndatabase is configurable and depend on the throughput needs of the\napplications. Databases in Redis Enterprise can be resharded into more\nRedis shards to scale throughput while maintaining sub-millisecond\nlatencies. Resharding is performed without downtime.\n\n\n\nRedis Enterprise places master shards and replicas in separate\nnodes, racks, and zones, and uses in-memory replication to protect data\nagainst failures.\n\nIn Redis Enterprise, each database has a quota of RAM. The quota cannot\nexceed the limits of the RAM available on the node. However, with Redis\nEnterprise Flash, RAM is extended to the local flash drive (SATA, NVMe\nSSDs etc). The total quota of the database can take advantage of both\nRAM and Flash drive. The administrator can choose the RAM vs Flash ratio\nand adjust that anytime in the lifetime of the database without\ndowntime.\n\nWith Auto Tiering, instead of storing all keys and data for a\ngiven shard in RAM, less frequently accessed values are pushed to flash.\nIf applications need to access a value that is in flash, Redis\nEnterprise automatically brings the value into RAM. Depending on the\nflash hardware in use, applications experience slightly higher latency\nwhen bringing values back into RAM from flash. However subsequent\naccesses to the same value is fast, once the value is in RAM.\n\n## Client-side caching\n\nClient-side caching allows Redis clients to store a subset of data in a local cache and avoid sending repeated requests to the Redis database. When used to cache frequently accessed data, this technique can improve performance by decreasing network traffic, latency, and load on the database. For more information about client-side caching, see the [client-side caching introduction]().\n\nRedis Software supports client-side caching for databases with Redis versions 7.4 and later. See [Client-side caching compatibility with Redis Software]() for more information about compatibility and configuration options.\n",
  "tags": ["docs","operate","rs"],
  "last_updated": "2026-04-01T08:10:08-05:00",
  "children": [{"id":"eviction-policy","summary":"The eviction policy determines what happens when a database reaches its memory limit.","title":"Eviction policy","url":"https://redis.io/docs/latest/operate/rs/7.8/databases/memory-performance/eviction-policy/"},{"id":"memory-limit","summary":"When you set a database's memory limit, you define the maximum size the database can reach.","title":"Database memory limits","url":"https://redis.io/docs/latest/operate/rs/7.8/databases/memory-performance/memory-limit/"},{"id":"shard-placement-policy","summary":"Detailed info about the shard placement policy.","title":"Shard placement policy","url":"https://redis.io/docs/latest/operate/rs/7.8/databases/memory-performance/shard-placement-policy/"}]
}