Redis Flex V2: Choosing the Right RAM Ratio and Troubleshooting Performance

Redis Flex enables large datasets to be stored using a combination of RAM and SSD while keeping frequently accessed data in memory for low-latency access. Unlike traditional all-memory Redis deployments, Flex allows you to tune the percentage of data maintained in RAM and stored on SSD, giving you additional control over performance, throughput, and cost.

This article explains how Redis Flex V2 RAM ratios affect database behavior, how to choose the right RAM allocation for your workload, how RAM ratios influence performance and cost, and how to troubleshoot common Flex sizing and performance questions.

If you are investigating latency, memory pressure, or flash utilization issues, review the Troubleshooting section below.

Quick Fix

Understanding Redis Flex RAM Ratios

Redis Flex stores hot data in RAM and colder data on SSD. The RAM ratio determines how much of the total dataset capacity is allocated to memory.

Supported ratios currently range from 10% to 50%.

For example:

• A 10% ratio allocates less memory and prioritizes cost efficiency.

• A 50% ratio allocates more memory and prioritizes performance.

• Intermediate ratios balance cost and performance characteristics.

The optimal ratio depends on:

• Dataset size

• Working set size

• Access patterns

• Throughput requirements

• Latency requirements

• Budget constraints

How RAM Ratios Affect Performance

In Redis Flex, frequently accessed data remains in memory while less frequently accessed data is served from SSD.

As RAM allocation increases:

• More hot data can remain in memory.

• Flash reads may decrease.

• Throughput capacity may increase.

• Latency consistency may improve during peak workloads.

As RAM allocation decreases:

• Infrastructure costs may decrease.

• More data may be served from SSD.

• Workloads with large working sets may experience additional flash activity.

The actual impact depends heavily on workload characteristics. Applications with highly predictable access patterns often perform well at lower RAM ratios, while workloads with larger or rapidly changing working sets may benefit from additional memory.

Choosing the Right RAM Ratio

Start with 10%–20% RAM when:

• Cost optimization is the primary goal.

• Most data is rarely accessed.

• Access patterns are highly skewed toward a small working set.

• Latency requirements are moderate.

Consider 30%–40% RAM when:

• The workload experiences sustained traffic.

• The working set changes throughout the day.

• Throughput requirements are increasing.

• Flash activity is higher than expected.

Consider 50% RAM when:

• Low latency is a critical requirement.

• A large percentage of the dataset is actively accessed.

• The workload requires the highest available Flex performance profile.

• You are troubleshooting memory residency limitations caused by an unusually large working set.

Monitoring Redis Flex Effectively

When evaluating Flex performance, focus on workload behavior rather than SSD usage alone.

Monitor:

• Memory utilization

• Throughput

• Operations per second

• Latency

• Database memory pressure

• Flash activity trends

• Application response times

A high level of SSD utilization is not automatically a problem. Redis Flex is designed to serve cold data from SSD as part of normal operation.

Instead, investigate situations where increased flash activity coincides with:

• Higher latency

• Reduced throughput

• Increased application response times

• Memory pressure alerts

Troubleshooting Performance Questions

Performance is lower than expected

Possible causes:

• RAM ratio is too low for the workload.

• Working set size is larger than expected.

• Traffic patterns changed after deployment.

• Dataset growth exceeded the original sizing assumptions.

Recommended actions:

1. Review latency and throughput metrics.

2. Verify current memory utilization.

3. Compare current workload characteristics with the original sizing assumptions.

4. Consider increasing the RAM ratio if the workload is consistently serving active data from SSD.

SSD activity appears high

Possible causes:

• Expected Flex behavior.

• Large cold dataset.

• Working set larger than available RAM.

Recommended actions:

1. Check application latency.

2. Review memory pressure indicators.

3. Determine whether flash activity is affecting user-facing performance before making sizing changes.

Cost is higher than expected

Possible causes:

• RAM ratio configured higher than necessary.

• Workload no longer requires previous performance levels.

• Dataset sizing assumptions changed.

Recommended actions:

1. Review utilization and performance metrics.

2. Identify the actual working set size.

3. Evaluate whether a lower RAM ratio would still satisfy performance requirements.

Latency increased after workload growth

Possible causes:

• Working set expanded beyond available RAM.

• Traffic characteristics changed.

• Dataset growth reduced hot-data residency.

Recommended actions:

1. Review latency trends and flash activity.

2. Verify memory utilization.

3. Consider increasing the RAM ratio or overall database capacity.

Common Sizing Examples

Semantic caching workloads

Typically characterized by:

• Large datasets

• Highly skewed access patterns

• Small hot working sets

Often suitable for lower RAM ratios.

Feature stores and recommendation systems

Typically characterized by:

• Large active datasets

• Frequent reads

• Consistent access patterns

Often benefit from moderate RAM ratios.

Real-time applications

Typically characterized by:

• High throughput

• Strict latency requirements

• Large active working sets

Often benefit from higher RAM ratios.

Additional Considerations

Increasing the RAM ratio does not require application changes and does not alter how clients interact with Redis. The change affects how Redis Flex allocates resources between memory and SSD, allowing you to adjust the balance between performance and cost as workload requirements evolve.

Because workload characteristics change over time, periodically review memory utilization, throughput, latency, and flash activity to confirm that the selected RAM ratio continues to match your application's requirements.