From 2a954784964fc0f4aef515c8e1c73322760efa03 Mon Sep 17 00:00:00 2001 From: Rachel Elledge Date: Mon, 9 Mar 2026 14:11:50 -0500 Subject: [PATCH 01/10] DOC-6286 RS: Created placeholder for new top-level Redis Flex section/overview --- content/operate/rs/flex/_index.md | 93 +++++++++++++++++++++++++++++++ 1 file changed, 93 insertions(+) create mode 100644 content/operate/rs/flex/_index.md diff --git a/content/operate/rs/flex/_index.md b/content/operate/rs/flex/_index.md new file mode 100644 index 0000000000..23e30f1ec4 --- /dev/null +++ b/content/operate/rs/flex/_index.md @@ -0,0 +1,93 @@ +--- +Title: Flex databases +alwaysopen: false +categories: +- docs +- operate +- rs +- rc +description: Extend Redis databases with flash storage for large-scale, cost-efficient deployments. +hideListLinks: true +linktitle: Flex databases +weight: 38 +--- + +Flex extends your database capacity by combining RAM and flash (SSD) storage. This tiered architecture keeps frequently accessed (hot) data in RAM for sub-millisecond latency while storing less active (warm) data on flash to reduce costs and increase capacity. + +Flex databases work with your existing Redis applications and the Redis API without modification. + +## How Flex works + +### Automatic data tiering + +Flex moves data between RAM and flash based on access patterns: + +- Frequently accessed data stays in high-speed RAM. +- Less active data moves to cost-efficient flash storage. +- Data accessed from flash promotes back to RAM automatically. + +Redis uses an [LRU (least recently used)]({{< relref "/develop/reference/eviction#apx-lru" >}}) eviction policy to manage data placement. When memory pressure increases, Flex identifies cold objects, transfers them to flash, and frees RAM for new or frequently accessed keys. + +This process requires no application changes. Your existing Redis commands work across both storage tiers. + +### Storage engine + +Flex uses [Speedb](https://docs.speedb.io), a high-performance key-value storage engine optimized for flash drives: + +- Redis handles all data operations in memory. +- Speedb manages the flash storage layer. + +This design delivers predictable latency and throughput as datasets grow beyond RAM limits. + +## Compatibility + +Flex is compatible with the Redis API and supports all Redis data types, including JSON and probabilistic data structures (Bloom filters, Count-Min Sketch, Top-K). + +The following features are not yet supported with Flex: + +- Redis Search +- Time series +- Active-Active + +## When to use Flex + +Use Flex when you need to: + +- Run Redis at terabyte scale while maintaining high throughput and sub-10 ms latency +- Power real-time feature stores for machine learning applications +- Operate large distributed caches with elastic scaling and consistent performance under heavy load +- Reduce infrastructure costs by combining high-speed RAM with cost-efficient flash storage + +{{}} +Flex does not replace long-term data persistence. For workloads that require durability and recovery across restarts or failures, use Redis persistence features like [AOF (Append-Only File)]({{< relref "/operate/oss_and_stack/management/persistence#append-only-file" >}}), [RDB snapshots]({{< relref "/operate/oss_and_stack/management/persistence#snapshotting" >}}), or both. For more information, see [Database persistence]({{< relref "/operate/rs/databases/configure/database-persistence" >}}). +{{}} + +## Flex and Auto Tiering + +Flex replaces [Auto Tiering]({{< relref "/operate/rs/7.22/databases/auto-tiering" >}}) (formerly known as Redis on Flash). Redis Software selects the implementation based on your Redis version: + +| Redis database version | Flex | Auto Tiering | +|------------------------|------|--------------| +| 8.0 and later | ✅ | ❌ | +| 7.4 | ✅ | ✅| +| 7.2 and earlier | ❌ | ✅ | + +For Redis Software version 7.22.2-22 or earlier, see [Auto Tiering]({{< relref "/operate/rs/7.22/databases/auto-tiering" >}}). + +### Differences between Flex and Auto Tiering + +- Key and value offloading + - Auto Tiering offloads only values to flash while keys remain in RAM. + - Flex offloads both keys and values, which increases dataset density per node and reduces RAM consumption. +- RAM population strategy + - Auto Tiering fills all available RAM before offloading data to flash. This maximizes hot-data performance but can cause non-linear performance changes at high utilization. + - Flex uses utilization-aware RAM population. When database utilization is below 50%, Flex uses up to 50% of configured RAM for hot data. Above 50% utilization, Flex uses both RAM and flash proportionally, following the configured RAM-to-flash ratio. This provides a stable performance curve, consistent RAM hit-rate, and predictable throughput and latency. +- Storage engine + - Auto Tiering uses either RocksDB or Speedb as the storage engine. + - Flex uses Speedb only. + +## Next steps + +- [Plan your deployment]({{< relref "/operate/rs/flex/plan" >}}): Review hardware requirements, sizing guidelines, and limitations. +- [Get started]({{< relref "/operate/rs/flex/get-started" >}}): Configure Flex on your cluster. +- [Scale your deployment]({{< relref "/operate/rs/flex/scale" >}}): Learn scaling strategies and best practices. From f029f929006bef14441668b6b196f69daa7a4524 Mon Sep 17 00:00:00 2001 From: Rachel Elledge Date: Mon, 9 Mar 2026 14:29:10 -0500 Subject: [PATCH 02/10] DOC-6288 RS: Added Redis Flex quickstart --- content/operate/rs/flex/get-started.md | 123 +++++++++++++++++++++++++ 1 file changed, 123 insertions(+) create mode 100644 content/operate/rs/flex/get-started.md diff --git a/content/operate/rs/flex/get-started.md b/content/operate/rs/flex/get-started.md new file mode 100644 index 0000000000..43ae0dc0d0 --- /dev/null +++ b/content/operate/rs/flex/get-started.md @@ -0,0 +1,123 @@ +--- +Title: Get started with Flex databases for Redis Software +alwaysopen: false +categories: +- docs +- operate +- rs +description: Configure Flex databases on your Redis Software cluster. +linkTitle: Get started +weight: 20 +--- +This page guides you through a quick setup of [Flex]({{< relref "/operate/rs/flex" >}}) with a single node for testing and demo purposes. + +For production environments, you can find more detailed installation instructions in the [install and setup]({{< relref "/operate/rs/installing-upgrading" >}}) section. + +To set up a Redis Software cluster using Flex +with a single node: + +1. [Install Redis Software](#install-redis-software) or run it in a [Docker container](#dockerbased-installation). + +1. [Prepare and format flash memory](#prepare-and-format-flash-memory). + +1. [Set up a cluster](#setup-cluster-flash) with flash storage. + +1. [Create a new database](#create-a-database) with flash enabled. + +1. [Connect to your new database](#connect-to-your-database). + +## Install Redis Software + +### Bare metal, VM, Cloud instance + +To install on bare metal, a virtual machine, or an instance: + +1. Download the Redis Software binaries from the [download center](https://redis.io/downloads/#Redis_Software). + +1. Upload the binaries to a Linux-based operating system. + +1. Extract the image: + + ```sh + tar -vxf + ``` + +1. After the `tar` command completes, you can find a new `install.sh` script in the current directory: + + ```sh + sudo ./install.sh -y + ``` + +### Docker-based installation {#dockerbased-installation} + +For testing purposes, you can run a Redis Software Docker container: + +```sh +docker run -d --cap-add sys_resource --name rp -p 8443:8443 -p 12000:12000 redislabs/redis:latest +``` + +## Prepare and format flash memory + +After you [install Redis Software](#install-redis-enterprise-software), use the `prepare_flash` script to prepare and format flash memory: + +```sh +sudo /opt/redislabs/sbin/prepare_flash.sh +``` + +This script finds unformatted disks and mounts them as RAID partitions in `/var/opt/redislabs/flash`. + +To verify the disk configuration, run: + +```sh +sudo lsblk +``` + +## Set up a cluster with flash storage {#setup-cluster-flash} + +1. Direct your browser to `https://localhost:8443` on the host machine to +see the Redis Software Cluster Manager UI. + + {{}} +Depending on your browser, you may see a certificate error. +Choose "continue to the website" to go to the setup screen. + {{}} + +1. Click **Create new cluster**. + +1. Set up account credentials for a cluster administrator, then click **Next** to proceed to cluster setup. + +1. Enter your cluster license key if you have one. Otherwise, the cluster uses the trial version. + +1. Provide a cluster FQDN such as `mycluster.local`, then click **Next**. + +1. In the **Storage configuration** section, turn on the **Enable flash storage** toggle. + +1. Click **Create cluster**. + +1. Click **OK** to confirm that you are aware of the replacement of the HTTPS TLS certificate on the node, and proceed through the browser warning. + +## Create a database + +On the **Databases** screen: + +1. Select **Quick database**. + +1. Verify **Flash** is selected for **Runs on**. + + {{Create a quick database with Runs on Flash selected.}} + +1. Enter `12000` for the endpoint **Port** number. + +1. Optionally, select **Full options** to see available alerts. + +1. Click **Create**. + +You now have a Flex database. + +## Connect to your database + +After you create the database, you can connect to it and store data. See [Test client connection]({{}}) for connection options and examples. + +## Next steps + +To see the true performance and scale of Flex, you must tune your I/O path and set the flash path to the mounted path of SSD or NVMe flash memory. From c23b6f1cc3b694ed2dacb1346e175d87efe4f0f5 Mon Sep 17 00:00:00 2001 From: Rachel Elledge Date: Mon, 9 Mar 2026 16:58:23 -0500 Subject: [PATCH 03/10] DOC-6289 RS: Added Redis Flex planning --- content/operate/rs/flex/plan.md | 102 ++++++++++++++++++++++++++++++++ 1 file changed, 102 insertions(+) create mode 100644 content/operate/rs/flex/plan.md diff --git a/content/operate/rs/flex/plan.md b/content/operate/rs/flex/plan.md new file mode 100644 index 0000000000..b74c06c943 --- /dev/null +++ b/content/operate/rs/flex/plan.md @@ -0,0 +1,102 @@ +--- +title: Plan a Flex deployment for Redis Software +alwaysopen: false +categories: +- docs +- operate +- rs +description: Hardware requirements, sizing guidelines, best practices, and limitations for Flex databases on Redis Software. +hideListLinks: true +linkTitle: Plan deployment +weight: 10 +--- + +Review the following hardware requirements, sizing guidelines, best practices, and known limitations before you deploy a Redis Software cluster for Flex databases. + +## Version requirements + +To create Flex databases, you need: + +- Redis Software cluster version 8.0.2-17 or later + +- Redis database version 8.2 or later + +## Hardware requirements + +When planning a Flex deployment, consider the following flash drive requirements: + +- Flash storage must be locally attached. Network-attached storage (NAS), storage area networks (SAN), or solutions such as AWS Elastic Block Storage (EBS) are not supported. + +- Flash storage must be dedicated to Flex database data and keys. It should not be used for durability, binaries, or persistence. + +- For the best performance, the SSDs should be NVMe based. NVMe Gen 5 or Gen 4 is recommended. Gen 3 is also supported, but not recommended for best performance. + +- Flash storage must be greater than the total provisioned database size to account for write buffers, space amplification, and more. + +See the general Redis Software [hardware requirements]({{}}) for additional requirements. + +## Sizing guidelines + +Size your Redis Flex databases based on data volume, shard count, RAM-to-flash ratio, and CPU allocation to balance capacity, throughput, and latency. + +### Shard size + +Flex databases consist of shards—independent data partitions that handle a portion of the dataset and request load. Each shard runs as a self-contained Redis process with dedicated memory, CPU, and flash resources. + +Use these standard building blocks to plan capacity: + +- 50 GB per shard + +- Allocate 1 vCPU per shard + +For example, a 1 TB dataset requires 20 shards, with 50 GB per shard. + +### CPU allocation + +Throughput capacity scales with both CPU cores. At minimum, allocate 1 vCPU per 50 GB shard. + +### RAM-to-flash ratio + +The RAM-to-flash ratio directly affects throughput and latency: + +- More RAM increases throughput and lowers latency. + +- Less RAM lowers throughput and increases latency, but reduces cost. + +Actual performance can vary based on your data model, commands, and network latency. + +## Feature and data type compatibility + +| Data type/feature | Flex support | +|------------------|--------------| +| [Active-Active databases]({{}}) | ❌Not supported | +| [JSON]({{}}) | ✅ Supported | +| [Probabilistic data structures]({{}}) | ✅ Supported | +| [Redis Search]({{}}) | ❌Not supported | +| Standard [Redis data types]({{}}) | ✅ Supported | +| [Time series]({{}}) | ❌Not supported | + +## Best practices + +- Store small keys and values when possible. Avoid objects larger than 10 KB, which can reduce performance because the entire value moves between RAM and flash. + +- Start with a balanced ratio, such as 20% RAM to 80% flash, and monitor latency and throughput metrics. + +- Increase RAM percentage if 99th-percentile latency exceeds your target or cache hit rates drop. + +- Decrease RAM percentage if memory utilization is high but latency remains stable to lower cost and improve efficiency. + +- Re-evaluate the ratio of RAM to flash periodically as dataset size and access patterns evolve. + +## Known limitations + +- Flex databases cannot store keys or values larger than 4GB in flash storage. Larger keys or values will be stored in RAM only, and warnings will appear in the Redis logs: + + ```sh + # WARNING: key too big for disk driver, size: 4703717276, key: subactinfo:htable + ``` + +## Next steps + +- [Get started]({{< relref "/operate/rs/flex/get-started" >}}): Configure Flex on your cluster. +- [Scale your deployment]({{< relref "/operate/rs/flex/scale" >}}): Learn scaling strategies. \ No newline at end of file From d244b0d1195e645eff14b91e8c367c2baf7c9578 Mon Sep 17 00:00:00 2001 From: Rachel Elledge Date: Tue, 10 Mar 2026 17:23:02 -0500 Subject: [PATCH 04/10] DOC-6290 RS: Added scaling Redis Flex page --- content/operate/rs/flex/scale.md | 138 +++++++++++++++++++++++++++++++ 1 file changed, 138 insertions(+) create mode 100644 content/operate/rs/flex/scale.md diff --git a/content/operate/rs/flex/scale.md b/content/operate/rs/flex/scale.md new file mode 100644 index 0000000000..ddc0bb4cc9 --- /dev/null +++ b/content/operate/rs/flex/scale.md @@ -0,0 +1,138 @@ +--- +title: Scale Flex databases for Redis Software +alwaysopen: false +categories: +- docs +- operate +- rs +description: Scaling strategies for Flex deployments for Redis Software. +hideListLinks: true +linkTitle: Scale +weight: 30 +--- + +This guide shows you how to scale Flex databases for Redis Software to meet changing workload demands. + +## Choose a scaling strategy + +Use the following table to determine the best scaling strategy for your Flex deployment: + +| Goal | Recommended action | +|------|--------------------| +| Increase data capacity only without adding CPU | Increase database limit and decrease RAM percentage | +| Increase throughput only | Add shards and vCPU | +| Increase data capacity and throughput | Add shards | +| Improve latency under higher load | Increase RAM percentage | +| Reduce cost while maintaining performance | Tune RAM-to-flash ratio | + +## Prerequisites + +Before you scale a self-managed Flex deployment, verify that your cluster has sufficient resources, such as memory, disk, and vCPU. + +## Scale volume + +If your dataset requires more capacity while maintaining performance, you can prepare a Flex database to store more data using one of the following options: + +1. Increase the database limit and [add shards](scale-volume-add-shards). + +1. Increase the database limit and [decrease the RAM-to-flash ratio](#decrease-ram-to-flash-ratio). + +### Add shards {#scale-volume-add-shards} + +You can add more shards to expand dataset capacity while maintaining the existing RAM-to-flash ratio. Throughput capacity also typically increases as a result of additional shards and infrastructure. This strategy is recommended when the dataset size and traffic are expected to grow together. + +Before you increase the dataset capacity and add shards, you need to add more RAM and vCPUs to handle the increased number of shards. + +To increase the dataset capacity and shards using the Cluster Manager UI: + +1. On the **Databases** screen, select the database you want to edit. + +1. From the **Configuration** tab, click **Edit**. + +1. In the **Capacity** section, increase the **Memory limit**. + +1. In the **Clustering** section, increase the **Number of shards**. + +1. Click **Save**. + +### Decrease RAM-to-flash ratio + +You can allocate more data to the flash tier while keeping the same amount of RAM to increase the database capacity. This strategy increases the total volume without requiring additional RAM or vCPU. +Maintains existing shard count while improving hardware utilization. +Recommended when: scaling for volume only, and SSD resources are underutilized. + +This will increase the DB with flash storage without needing additional vCPU or memory. Usually best for when scaling only volume is required and there is unutilized SSD space. + +To increase the dataset capacity and decrease the RAM-to-flash ratio using the Cluster Manager UI: + +1. On the **Databases** screen, select the database you want to edit. + +1. From the **Configuration** tab, click **Edit**. + +1. In the **Capacity** section: + + 1. Increase the **Memory limit**. + + 1. Decrease the **RAM limit**. + +1. Click **Save**. + +## Scale throughput + +If your workload's read/write rate increases and latency starts to rise, you can prepare the database to handle more traffic using one of the following strategies: + +1. [Add shards or nodes](#add-shards-or-nodes). + +1. [Increase the RAM-to-flash ratio](#increase-ram-to-flash-ratio). + +### Add shards or nodes + +You can add more shards or nodes to distribute traffic and increase throughput without changing the RAM-to-flash ratio. Dataset size capacity also typically increases as a result of additional shards and infrastructure. This strategy is recommended when the dataset size and traffic are expected to grow together. + +Before you add shards or nodes, you need to add more RAM and vCPUs to handle the increased number of shards or nodes. + +To add shards using the Cluster Manager UI: + +1. On the **Databases** screen, select the database you want to edit. + +1. From the **Configuration** tab, click **Edit**. + +1. In the **Clustering** section, increase the **Number of shards**. + +1. Click **Save**. + +To add nodes to the cluster, see [Add a node]({{}}) for instructions. + +### Increase RAM-to-flash ratio + +To improve throughput and lower latency, you can expand the in-memory tier to serve a higher proportion of requests directly from RAM. This strategy is recommended when low latency is your primary goal and you don't need to increase the dataset size. + +Before increasing the RAM-to-flash ratio, you might need to add more nodes to accommodate additional RAM. See [Add a node]({{}}) for instructions. + +To increase the RAM-to-flash ratio using the Cluster Manager UI: + +1. On the **Databases** screen, select the database you want to edit. + +1. From the **Configuration** tab, click **Edit**. + +1. In the **Capacity** section, increase the **RAM limit**. + +1. Click **Save**. + +## Scale infrastructure + +You can increase or adjust the underlying resources supporting the database, such as CPU, memory, and disk. + +For self-managed Redis Flex deployments, ensure the cluster has sufficient physical resources before scaling. The cluster requires: + +- Enough RAM to support the desired in-memory dataset size. + +- Enough SSD capacity for flash-tier data. + +- Adequate vCPU to support increased shard count or throughput. + +{{}} +Scaling operations will fail or underperform if the underlying cluster is resource-constrained. +{{}} + +See Flex [hardware requirements]({{}}) for more information. From b66c65431f3ec9dd363d3e0cd34737f14ec586e6 Mon Sep 17 00:00:00 2001 From: Rachel Elledge Date: Tue, 10 Mar 2026 17:37:38 -0500 Subject: [PATCH 05/10] DOC-6290 RS: Small edits/fixes for scaling Flex --- content/operate/rs/flex/scale.md | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/content/operate/rs/flex/scale.md b/content/operate/rs/flex/scale.md index ddc0bb4cc9..65ba78a5cf 100644 --- a/content/operate/rs/flex/scale.md +++ b/content/operate/rs/flex/scale.md @@ -33,7 +33,7 @@ Before you scale a self-managed Flex deployment, verify that your cluster has su If your dataset requires more capacity while maintaining performance, you can prepare a Flex database to store more data using one of the following options: -1. Increase the database limit and [add shards](scale-volume-add-shards). +1. Increase the database limit and [add shards](#scale-volume-add-shards). 1. Increase the database limit and [decrease the RAM-to-flash ratio](#decrease-ram-to-flash-ratio). @@ -57,11 +57,7 @@ To increase the dataset capacity and shards using the Cluster Manager UI: ### Decrease RAM-to-flash ratio -You can allocate more data to the flash tier while keeping the same amount of RAM to increase the database capacity. This strategy increases the total volume without requiring additional RAM or vCPU. -Maintains existing shard count while improving hardware utilization. -Recommended when: scaling for volume only, and SSD resources are underutilized. - -This will increase the DB with flash storage without needing additional vCPU or memory. Usually best for when scaling only volume is required and there is unutilized SSD space. +You can allocate more data to the flash tier to increase the database capacity while keeping the same amount of RAM, shards, and vCPU. This strategy is recommended when scaling for volume only and SSD resources are underutilized. To increase the dataset capacity and decrease the RAM-to-flash ratio using the Cluster Manager UI: From 0a9fc1e7cd0152ed772854f31ab21fa107ed1a21 Mon Sep 17 00:00:00 2001 From: Rachel Elledge Date: Tue, 10 Mar 2026 17:39:59 -0500 Subject: [PATCH 06/10] Fixed broken anchor on Flex RS quickstart --- content/operate/rs/flex/get-started.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/operate/rs/flex/get-started.md b/content/operate/rs/flex/get-started.md index 43ae0dc0d0..5e7946881f 100644 --- a/content/operate/rs/flex/get-started.md +++ b/content/operate/rs/flex/get-started.md @@ -58,7 +58,7 @@ docker run -d --cap-add sys_resource --name rp -p 8443:8443 -p 12000:12000 redis ## Prepare and format flash memory -After you [install Redis Software](#install-redis-enterprise-software), use the `prepare_flash` script to prepare and format flash memory: +After you [install Redis Software](#install-redis-software), use the `prepare_flash` script to prepare and format flash memory: ```sh sudo /opt/redislabs/sbin/prepare_flash.sh From eeee48181229f85431d7a9bfedffa927a4437eab Mon Sep 17 00:00:00 2001 From: Rachel Elledge Date: Thu, 19 Mar 2026 10:56:10 -0500 Subject: [PATCH 07/10] DOC-6288 Feedback updates for RS Flex quick start --- content/operate/rs/flex/get-started.md | 15 ++++++++++++--- 1 file changed, 12 insertions(+), 3 deletions(-) diff --git a/content/operate/rs/flex/get-started.md b/content/operate/rs/flex/get-started.md index 5e7946881f..2f6e64eb3f 100644 --- a/content/operate/rs/flex/get-started.md +++ b/content/operate/rs/flex/get-started.md @@ -11,10 +11,11 @@ weight: 20 --- This page guides you through a quick setup of [Flex]({{< relref "/operate/rs/flex" >}}) with a single node for testing and demo purposes. -For production environments, you can find more detailed installation instructions in the [install and setup]({{< relref "/operate/rs/installing-upgrading" >}}) section. +For production environments, see [Plan a Flex deployment for Redis Software]({{}}) and more detailed installation instructions in the [install and setup]({{< relref "/operate/rs/installing-upgrading" >}}) section. -To set up a Redis Software cluster using Flex -with a single node: +To set up a Redis Software cluster using Flex with a single node: + +1. Review the [version requirements](#version-requirements). 1. [Install Redis Software](#install-redis-software) or run it in a [Docker container](#dockerbased-installation). @@ -26,6 +27,14 @@ with a single node: 1. [Connect to your new database](#connect-to-your-database). +## Version requirements + +To create Flex databases, you need: + +- Redis Software cluster version 8.0.2-17 or later + +- Redis database version 8.2 or later + ## Install Redis Software ### Bare metal, VM, Cloud instance From 1c6757f225c843ba57ec33f2869140f5414a5bc4 Mon Sep 17 00:00:00 2001 From: Rachel Elledge Date: Thu, 19 Mar 2026 16:03:25 -0500 Subject: [PATCH 08/10] DOC-6290 Feedback updates for scaling RS Flex --- content/operate/rs/flex/scale.md | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/content/operate/rs/flex/scale.md b/content/operate/rs/flex/scale.md index 65ba78a5cf..3c6e76cfe7 100644 --- a/content/operate/rs/flex/scale.md +++ b/content/operate/rs/flex/scale.md @@ -59,6 +59,8 @@ To increase the dataset capacity and shards using the Cluster Manager UI: You can allocate more data to the flash tier to increase the database capacity while keeping the same amount of RAM, shards, and vCPU. This strategy is recommended when scaling for volume only and SSD resources are underutilized. +This scaling strategy increases capacity without adding CPU or RAM, but might reduce RAM hit rate and increase p99 latency. You should monitor metrics before and after this change. + To increase the dataset capacity and decrease the RAM-to-flash ratio using the Cluster Manager UI: 1. On the **Databases** screen, select the database you want to edit. @@ -73,6 +75,12 @@ To increase the dataset capacity and decrease the RAM-to-flash ratio using the C 1. Click **Save**. +For example, to lower the RAM-to-flash ratio from 30% to 20% on a 1 TB database: + +- You can increase the memory limit from 1 TB to 1.5 TB for more total capacity. + +- If you keep the RAM limit at 300 GB, it becomes 20% of the new total capacity. + ## Scale throughput If your workload's read/write rate increases and latency starts to rise, you can prepare the database to handle more traffic using one of the following strategies: From caf2bb486d5bbb84c34548ce404d5842696a58f1 Mon Sep 17 00:00:00 2001 From: Rachel Elledge Date: Thu, 19 Mar 2026 16:15:05 -0500 Subject: [PATCH 09/10] DOC-6289 Feedback updates for RS Flex planning --- content/operate/rs/flex/plan.md | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/content/operate/rs/flex/plan.md b/content/operate/rs/flex/plan.md index b74c06c943..3b02413570 100644 --- a/content/operate/rs/flex/plan.md +++ b/content/operate/rs/flex/plan.md @@ -13,6 +13,16 @@ weight: 10 Review the following hardware requirements, sizing guidelines, best practices, and known limitations before you deploy a Redis Software cluster for Flex databases. +## Checklist + +Before you deploy Flex, verify: + +```checklist {id="rs-flex-list"} +- [ ] You have locally attached NVMe or SSD dedicated to Flex data and keys. +- [ ] The flash capacity is greater than the total provisioned database size. +- [ ] Your working set is much smaller than the total dataset and fits a high-RAM hit-rate pattern. +``` + ## Version requirements To create Flex databases, you need: @@ -53,7 +63,7 @@ For example, a 1 TB dataset requires 20 shards, with 50 GB per shard. ### CPU allocation -Throughput capacity scales with both CPU cores. At minimum, allocate 1 vCPU per 50 GB shard. +Throughput capacity scales with both CPU cores and the RAM-to-flash ratio. At minimum, allocate 1 vCPU per 50 GB shard. ### RAM-to-flash ratio From 87b3b0d40aa6fc18c818ed1efcb06cbc9578da72 Mon Sep 17 00:00:00 2001 From: Rachel Elledge Date: Thu, 19 Mar 2026 16:22:43 -0500 Subject: [PATCH 10/10] DOC-6286 Feedback updates for Flex overview --- content/operate/rs/flex/_index.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/operate/rs/flex/_index.md b/content/operate/rs/flex/_index.md index 23e30f1ec4..5f3ed5d299 100644 --- a/content/operate/rs/flex/_index.md +++ b/content/operate/rs/flex/_index.md @@ -12,7 +12,7 @@ linktitle: Flex databases weight: 38 --- -Flex extends your database capacity by combining RAM and flash (SSD) storage. This tiered architecture keeps frequently accessed (hot) data in RAM for sub-millisecond latency while storing less active (warm) data on flash to reduce costs and increase capacity. +Flex extends your database capacity by combining RAM and flash (SSD) storage. This tiered architecture keeps frequently accessed (hot) data in RAM for sub-millisecond latency while storing less active (warm) data on flash to reduce costs and increase capacity. Flex frees RAM for hot data, leads to a higher RAM hit rate, and allows bigger datasets per node. Flex databases work with your existing Redis applications and the Redis API without modification. @@ -78,7 +78,7 @@ For Redis Software version 7.22.2-22 or earlier, see [Auto Tiering]({{< relref " - Key and value offloading - Auto Tiering offloads only values to flash while keys remain in RAM. - - Flex offloads both keys and values, which increases dataset density per node and reduces RAM consumption. + - Flex offloads both keys and values, which increases dataset density per node and reduces RAM consumption. This change frees RAM for hot data, leads to a higher RAM hit rate, and allows bigger datasets per node. - RAM population strategy - Auto Tiering fills all available RAM before offloading data to flash. This maximizes hot-data performance but can cause non-linear performance changes at high utilization. - Flex uses utilization-aware RAM population. When database utilization is below 50%, Flex uses up to 50% of configured RAM for hot data. Above 50% utilization, Flex uses both RAM and flash proportionally, following the configured RAM-to-flash ratio. This provides a stable performance curve, consistent RAM hit-rate, and predictable throughput and latency.