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
| Question | Answer |
|---|---|
| Why did my Redis Flex cost change? | Redis Flex V2 pricing is based on the configured RAM-to-SSD ratio. |
| Does increasing RAM improve performance? | In most workloads, increasing the RAM ratio can improve throughput and reduce flash reads. |
| Does changing the RAM ratio require application changes? | No. Applications continue to use Redis normally. |
| Can I change the RAM ratio after deployment? | Yes. Redis Flex supports configurable RAM ratios. |
| What RAM ratio should I choose? | Choose the lowest ratio that meets your performance and latency requirements. |
| Is a higher RAM ratio always better? | Not necessarily. Higher RAM ratios increase cost and may not provide meaningful benefits if your working set already fits in memory. |
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:
Review latency and throughput metrics.
Verify current memory utilization.
Compare current workload characteristics with the original sizing assumptions.
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:
Check application latency.
Review memory pressure indicators.
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:
Review utilization and performance metrics.
Identify the actual working set size.
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:
Review latency trends and flash activity.
Verify memory utilization.
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.
0 comments
Please sign in to leave a comment.