Flex v2 in Redis Cloud extends Redis databases beyond DRAM by combining RAM and dedicated Flash storage. Hot data stays in RAM for sub-millisecond access, while warm data moves to Flash to optimize cost and capacity. This guide explains how to select and size Flex databases, change the RAM-to-Flash ratio safely, monitor performance, and troubleshoot common behaviors using the Redis Cloud Console, API, or Redis Insight.
This article includes At a Glance, Prerequisites, Quick Fix Table, Sizing Guidance, Upgrade Behavior, Validation Checklist, Operations & Monitoring, Scaling, and Troubleshooting Summary.
At a Glance / Versioning Summary
| Category | Information |
|---|---|
| Availability | Supported on Redis Cloud Pro and Essentials plans (verify plan limits in the Console). |
| Version scope | Redis 8.2+ introduces Flex v2, enabling key + value offload and utilization-aware RAM management. |
| Best for | Large datasets with a smaller hot set and predictable data locality. |
| Change impact | RAM : Flash ratio updates are online but trigger an active resize that moves data between tiers and may briefly affect performance. |
| Active-Active (CRDB) | Not supported for Flex in Redis Cloud. |
Prerequisites
- Plan support: Confirm your Pro or Essentials plan includes Flex (visible in the database creation workflow).
- Change window: Schedule ratio edits during low-traffic periods; resizes are online but can impact performance.
- Backups: Ensure recent backups and validated restore tests.
- Observability: Use Redis Cloud metrics, Redis Insight, or your APM tool.
Quick Fix Table
| Problem | Fast check | Action |
|---|---|---|
| Cold-read latency spikes | RAM hit ratio; % values in RAM | Increase RAM %; pre-warm hot keys; improve locality |
| Throughput dip during change | Database resize status | Defer heavy workloads until resize completes; re-baseline performance |
| Unexpected evictions | Dataset vs configured memory; TTL churn | Increase capacity or RAM %; adjust eviction policy; audit TTLs |
| Replica lag | Region distance; replica CPU/IO | Co-locate regions; add replica RAM; verify bandwidth/IOPS |
| Cost spike | Recent configuration changes | Schedule changes during maintenance windows; monitor usage billable metrics |
Deployment Planning
Choosing When to Use Flex v2
Flex v2 is ideal for:
- Large datasets with predictable locality
- Workloads that tolerate slightly higher latency on cold reads
- Cost-sensitive deployments benefiting from Flash-backed capacity
Avoid Flex v2 when:
- Access patterns are uniform across the dataset
- The hot set ≈ total data size
- Required features (e.g., Active-Active) are unsupported in your plan
Plan Selection & Sizing
| Principle | Guidance |
|---|---|
| RAM ratio | Keep RAM ≥ 10%; start near 20% and adjust based on latency goals. |
| Resize impact | Changing RAM % triggers an online resize that moves data and may affect billing. |
| Storage headroom | Ensure Flash IOPS and throughput can absorb cold-read bursts. |
| Hot-set tuning | Track RAM hit ratio and p99 latency; increase RAM % if performance dips. |
Upgrade Behavior: Flex v1 → Flex v2 (Redis 8.2+)
| Question | Answer |
|---|---|
| Do I need to migrate manually? | No. Transition occurs automatically during upgrade to Redis 8.2. |
| Is downtime expected? | No downtime or data loss; handled within the standard upgrade workflow. |
| What changes after upgrade? | Database starts using Flex v2’s enhanced storage layer and key+value offload. |
| What should I verify afterward? | Latency, RAM hit ratio, Flash IOPS, resize activity. |
Summary: Redis 8.2 automatically transitions Flex v1 databases to Flex v2. No customer action required.
Sizing Example (10 TB Database, 30% RAM)
| Database utilization | RAM used | Flash used | Behavior |
|---|---|---|---|
| 40% (4 TB) | 1.5 TB | 2.5 TB | Higher hot-set residency in RAM |
| 70% (7 TB) | 2.1 TB | 4.9 TB | Proportional RAM/Flash growth for stable latency |
Validation Checklist
| Check | Target | How to verify |
|---|---|---|
| Latency (p99) | Within SLO | Cloud metrics / APM |
| RAM hit ratio | Meets design | Cloud metrics / Redis Insight |
| % values in RAM | Meets design | Cloud metrics |
| Evictions | No spikes | Console metrics and logs |
| Flash IOPS | Headroom | Cloud metrics |
Operating & Monitoring
Console path: Databases → (your database) → Configuration → Memory tiering
Ratio changes are online but trigger an active resize, which moves data between RAM and Flash. Schedule during a maintenance window and re-baseline performance afterward.
Monitor regularly:
- RAM hit ratio
- % values in RAM
- Avg/p99 latency
- Ops/sec
- Evictions and TTL churn
- Flash IOPS / throughput
- Replica lag
Use Redis Cloud metrics, Redis Insight, and/or your APM dashboards.
Scaling
| Goal | Action | Result |
|---|---|---|
| More capacity | Increase total DB size or lower RAM % | Expands Flash storage; cost-efficient for warm data |
| Higher throughput | Add shards (if available) | Increases parallelism and improves per-shard throughput |
| Better latency | Increase RAM % | Raises hot-data residency and lowers p99 latency |
Backups
Redis Flex is not a system of record.
Maintain scheduled backups and verify restores, especially before major size or ratio changes.
Troubleshooting Summary Table
| Symptom | Recommended action |
|---|---|
| Cold-read latency | Increase RAM %; pre-warm hot keys; verify Flash IOPS headroom. |
| Evictions | Increase RAM % or DB size; review TTL churn. |
| Resize side effects | Check active resize status; defer heavy workloads. |
| Replica lag | Add replica RAM; ensure geographic proximity and bandwidth sufficiency. |
| Unexpected RAM growth | Check for keys or values > 4 GB (remain in RAM and generate warnings). |
0 comments
Please sign in to leave a comment.