content/operate/rs/databases/memory-performance/memory-limit.md
When you set a database's memory limit, you define the maximum size the database can reach in the cluster, across all database replicas and shards, including both primary and replica shards.
If the total size of the database in the cluster reaches the memory limit, the data eviction policy is applied.
Factors to consider when sizing your database:
Additional factors for Active-Active databases:
[Active-Active replication]({{< relref "/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.
[database replication backlog]({{< relref "/operate/rs/databases/active-active/manage#replication-backlog/" >}}) for synchronization between shards. By default, this is set to 1% of the database size.
[Active-Active replication backlog]({{< relref "/operate/rs/databases/active-active/manage.md" >}}) for synchronization between clusters. By default, this is set to 1% of the database size.
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.
Additional factors for databases with Auto Tiering enabled:
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.
[database persistence]({{< relref "/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.
Redis 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.
Redis Software protects the existing data and prevents the database from being able to store data into the shards.
You can configure the cluster to move the data to another node, or even discard it according to the [eviction policy]({{< relref "/operate/rs/databases/memory-performance/eviction-policy.md" >}}) set on each database by the administrator.
[Redis Flex and Auto Tiering]({{< relref "/operate/rs/databases/flash/" >}}) manage memory so that you can also use flash memory (SSD) to store data.
We recommend that you have a [monitoring platform]({{< relref "/operate/rs/monitoring/" >}}) that alerts you before a system gets low on RAM. You must maintain sufficient free memory to make sure that you have a healthy Redis Software installation.
In 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.
For example, when pushing data at approximately 100 MB/sec into a 2 GB database:
Databases should return to their configured memory limits after data is removed according to the [eviction policy]({{<relref "/operate/rs/databases/memory-performance/eviction-policy/">}}) and [time-to-live (TTL)]({{<relref "/develop/using-commands/keyspace#key-expiration">}}).
If you observe this behavior, consider [monitoring]({{< relref "/operate/rs/monitoring/" >}}) memory usage and controlling the traffic load on the application side.
Resharding 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.
Resharding follows a three-stage process for each new shard:
When 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.
{{< note >}} Resharding 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. {{< /note >}}
Resharding duration increases linearly with the number of keys in your database. Key length and network traffic affect resharding duration:
Key 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).
Network 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.
The Cluster Manager UI provides metrics that can help you evaluate your memory use.
See [console metrics]({{< relref "/operate/rs/references/metrics" >}}) for more detailed information.