{
  "id": "memory-limit",
  "title": "Database memory limits",
  "url": "https://redis.io/docs/latest/operate/rs/8.0/databases/memory-performance/memory-limit/",
  "summary": "When you set a database's memory limit, you define the maximum size the database can reach.",
  "content": "When you set a database's memory limit, you define the maximum size the\ndatabase can reach in the cluster, across all database replicas and\nshards, including both primary and replica shards.\n\nIf the total size of the database in the cluster reaches the memory\nlimit, the data eviction policy is\napplied.\n\n## Factors for sizing\n\nFactors to consider when sizing your database:\n\n- **dataset size**: you want your limit to be above your dataset size to leave room for overhead.\n- **database throughput**: high throughput needs more shards, leading to a higher memory limit.\n- [**modules**](https://redis.io/docs/latest/operate/oss_and_stack/stack-with-enterprise): using modules with your database consumes more memory.\n- [**database clustering**](https://redis.io/docs/latest/operate/rs/databases/durability-ha/clustering.md): enables you to spread your data into shards across multiple nodes.\n- [**database replication**](https://redis.io/docs/latest/operate/rs/databases/durability-ha/replication.md): enabling replication doubles memory consumption.\n\nAdditional factors for Active-Active databases:\n\n- [**Active-Active replication**](https://redis.io/docs/latest/operate/rs/databases/active-active/_index.md): enabling Active-Active replication requires double the memory of regular replication, which can be up to two times (2x) the original data size per instance.\n- [**database replication backlog**](https://redis.io/docs/latest/operate/rs/databases/active-active/manage#replication-backlog/) for synchronization between shards. By default, this is set to 1% of the database size.\n- [**Active-Active replication backlog**](https://redis.io/docs/latest/operate/rs/databases/active-active/manage.md) for synchronization between clusters. By default, this is set to 1% of the database size.\n\n  It's also important to know Active-Active databases have a lower threshold for activating the eviction policy, because it requires propagation to all participating clusters. The eviction policy starts to evict keys when one of the Active-Active instances reaches 80% of its memory limit.\n\nAdditional factors for  databases with Auto Tiering enabled:\n\n- The available flash space must be greater than or equal to the total database size (RAM+Flash). The extra space accounts for write buffers and [write amplification](https://en.wikipedia.org/wiki/Write_amplification).\n\n- [**database persistence**](https://redis.io/docs/latest/operate/rs/databases/configure/database-persistence.md): Auto Tiering uses dual database persistence where both the primary and replica shards persist to disk. This may add some processor and network overhead, especially in cloud configurations with network attached storage.\n\n## What happens when Redis Software is low on RAM?\n\nRedis Software manages node memory so that data is entirely in RAM (unless using Auto Tiering). If not enough RAM is available, Redis Software prevents adding more data into the databases.\n\nRedis Software protects the existing data and prevents the database from being able to store data into the shards.\n\nYou can configure the cluster to move the data to another node, or even discard it according to the [eviction policy](https://redis.io/docs/latest/operate/rs/databases/memory-performance/eviction-policy.md) set on each database by the administrator.\n\n[Redis Flex and Auto Tiering](https://redis.io/docs/latest/operate/rs/databases/flash/)\nmanage memory so that you can also use flash memory (SSD) to store data.\n\n### Order of events for low RAM\n\n1. If there are other nodes available, your shards migrate to other nodes.\n2. If the eviction policy allows eviction, shards start to release memory,\nwhich can result in data loss.\n3. If the eviction policy does not allow eviction, you'll receive\nout of memory (OOM) messages.\n4. If shards can't free memory, Redis Software relies on the OS processes to stop replicas,\nbut tries to avoid stopping primary shards.\n\nWe recommend that you have a [monitoring platform](https://redis.io/docs/latest/operate/rs/monitoring/) that alerts you before a system gets low on RAM.\nYou must maintain sufficient free memory to make sure that you have a healthy Redis Software installation.\n\n### Active-Active replication OOM protection\n\nWhen a shard in an Active-Active database reaches an out-of-memory (OOM) condition:\n\n1. Replication between that shard and its peers stops immediately.\n\n1. The syncer process sends commands to the affected shard to trigger garbage collection and free memory.\n\nIf the database has no [eviction policy](https://redis.io/docs/latest/operate/rs/databases/memory-performance/eviction-policy/) and no keys with [expiration times (TTL)](https://redis.io/docs/latest/develop/using-commands/keyspace#key-expiration), no memory can be freed, which can lead to persistent replication failure and data desynchronization.\n\nTo reduce this risk, Active-Active databases running Redis version 8.4 or later support a configurable memory buffer through the `replication_oom_threshold_percent` setting. This setting reserves a percentage of memory below `maxmemory` for internal replication operations.\n\nThe `replication_oom_threshold_percent` setting works as follows:\n\n- If memory usage is below the threshold, all client writes proceed normally.\n\n- If memory usage exceeds the threshold, Redis blocks external client write commands with an out-of-memory error, but internal replication and garbage collection continue in the reserved buffer.\n\n- If memory reaches `maxmemory` despite the client block, the standard out-of-memory behavior applies to all operations, including replication.\n\n`replication_oom_threshold_percent` defaults to `5`, which means 5% of `maxmemory` is reserved. To adjust the reserved percentage in all participating clusters, use an [update Active-Active database configuration](https://redis.io/docs/latest/operate/rs/references/rest-api/requests/crdbs#patch-crdbs) REST API request:\n\n```sh\nPATCH https://\u003chost\u003e:\u003cport\u003e/v1/crdbs/\u003ccrdb_guid\u003e\n{ \n  \"default_db_config\": { \n    \"replication_oom_threshold_percent\": \u003cinteger from 0 to 20\u003e \n  }\n}\n```\n\n## Adaptive memory allocation\n\nIn rare cases during high-velocity data ingestion, databases can temporarily reach up to 200% of their configured memory limit. This adaptive memory allocation strategy allows large amounts of data to be written to the database quickly without rejecting valid transactions.\n\nFor example, when pushing data at approximately 100 MB/sec into a 2 GB database:\n- A database with 2 shards could reach 199% of its configured memory limit.\n- A database with 4 shards could reach around 220% of its configured memory limit.\n\nDatabases should return to their configured memory limits after data is removed according to the [eviction policy](https://redis.io/docs/latest/operate/rs/databases/memory-performance/eviction-policy/) and [time-to-live (TTL)](https://redis.io/docs/latest/develop/using-commands/keyspace#key-expiration).\n\nIf you observe this behavior, consider [monitoring](https://redis.io/docs/latest/operate/rs/monitoring/) memory usage and controlling the traffic load on the application side.\n\n## Resharding duration factors\n\nResharding enables you to increase database capacity by adding shards and utilizing more cluster memory. Understanding resharding duration helps you plan maintenance operations and minimize database risk.\n\n### Resharding overview\n\nResharding follows a three-stage process for each new shard:\n\n1. **Shard creation**: Creates a new shard and performs partial synchronization based on assigned hash slots\n2. **Key trimming**: Removes keys from the original shard according to new hash slot assignments\n3. **Defragmentation**: Executes failovers to optimize new shard performance\n\nWhen resharding multiple shards (for example, expanding from 4 to 8 shards), this process runs serially for each new shard. The operation completes only after all stages finish for every shard.\n\n\nResharding is an atomic operation that cannot be interrupted. Database corruption can occur if the process fails or stops unexpectedly. Minimizing resharding time reduces this risk.\n\n\n### Resharding duration factors\n\nResharding duration increases linearly with the number of keys in your database. Key length and network traffic affect resharding duration:\n\nKey length directly affects resharding duration. Longer keys (2000 KB) require more time to process due to increased hash calculation overhead per key compared to short keys (10 bytes). \n\nNetwork traffic has a measurable but limited effect on resharding duration. Since resharding operations typically don't reach CPU limits, the impact on both resharding time and ongoing traffic remains minimal.\n\n## Memory metrics\n\nThe Cluster Manager UI provides metrics that can help you evaluate your memory use.\n\n- Free RAM\n- RAM fragmentation\n- Used memory\n- Memory usage\n- Memory limit\n\nSee [console metrics](https://redis.io/docs/latest/operate/rs/references/metrics) for more detailed information.\n\n## Related info\n\n- [Memory and performance](https://redis.io/docs/latest/operate/rs/databases/memory-performance)\n- [Disk sizing for heavy write scenarios](https://redis.io/docs/latest/operate/rs/clusters/optimize/disk-sizing-heavy-write-scenarios.md)\n- [Turn off services to free system memory](https://redis.io/docs/latest/operate/rs/clusters/optimize/turn-off-services.md)\n- [Eviction policy](https://redis.io/docs/latest/operate/rs/databases/memory-performance/eviction-policy.md)\n- [Shard placement policy](https://redis.io/docs/latest/operate/rs/databases/memory-performance/shard-placement-policy.md)\n- [Database persistence](https://redis.io/docs/latest/operate/rs/databases/configure/database-persistence.md)\n",
  "tags": ["docs","operate","rs","rc"],
  "last_updated": "2026-07-23T11:57:56-05:00"
}