ElastiCache R5 vs R6g vs R7g: Valkey Performance with Memory Headroom

This is a fixed-workload analysis of nine one-hour Valkey 9.0 runs on Amazon ElastiCache: three each on cache.r5.large, cache.r6g.large, and cache.r7g.large. All used the same configured keyspace, command mix, load, and nine-worker client setup. AWS lists each of these node types with 13.07 GiB of memory. All nine runs ended with zero evictions and 27.1% to 33.6% memory headroom.

The sample does not form a simple generational performance ladder. The slowest R5 run still exceeded the best R6g run and the best R7g run. R6g and R7g occupied overlapping throughput bands, while R7g reported much lower engine CPU without taking the throughput lead. These are sustained-service observations with capacity remaining, not cache-cliff measurements or a universal CPU ranking.

Fixed-workload evidence with memory headroom

Node Arch. Median
ops/s		 Ops/s
range		 Median
latency		 Peak
memory		 Headroom Peak
CPU
r5.large Intel 48,891 47,932
51,268		 0.37 ms 69.49%
72.95%		 27.1%
30.5%		 50.1%
58.9%
r6g.large Graviton2 45,234 44,202
46,423		 0.40 ms 66.39%
68.67%		 31.3%
33.6%		 52.6%
53.5%
r7g.large Graviton3 46,509 44,582
46,789		 0.38 ms 67.61%
69.25%		 30.8%
32.4%		 36.5%
38.2%

Ranges show the observed low and high values across three runs, on separate lines. They are not negative values. All nine runs recorded zero evictions. Peak CPU is the reported ElastiCache engine CPU value.

R5 remains above both observed Graviton bands

R5 posted the highest median at 48,891 ops/s. R7g was 4.9% below that median and R6g was 7.5% below it. R5's highest run reached 51,268 ops/s, but the more useful separation is at the lower bound: no R6g or R7g run crossed R5's minimum of 47,932 ops/s. That is stronger evidence than a median-only ranking, while remaining limited to this Valkey version, workload shape, node size, and three-run sample.

R6g and R7g do not form separate outcome bands

The R6g and R7g ranges overlap from 44,582 to 46,423 ops/s. R6g's lowest run reached 44,202 ops/s, while R7g's lowest run reached 44,582. R7g's median was 2.8% above R6g's, but that small shift did not create a clean generation-to-generation separation. Median latency also stayed within a narrow 0.37 ms to 0.40 ms band across all three families.

Lower engine CPU did not become a throughput lead

R7g reported 36.5% to 38.2% peak engine CPU, well below R5 at 50.1% to 58.9% and R6g at 52.6% to 53.5%. Yet R5 served the highest throughput, and the R7g outcome band still overlapped R6g. The lower CPU reading may indicate more main-engine headroom, but it does not by itself prove greater end-to-end efficiency or additional application capacity. Client limits, I/O handling, latency under higher load, and the next saturation point would need separate evidence.

Peak key count confounds a memory-efficiency ranking

Peak key count ranged from 5,076,554 to 5,582,547 across the nine runs, a spread of almost 10%. R5 reached 5.32 to 5.58 million keys, R6g 5.08 to 5.25 million, and R7g 5.17 to 5.30 million. The peak-memory percentages therefore combine architecture and object overhead with the amount of data actually present at the end of each run. R5's higher peak memory cannot be called worse memory efficiency, just as the lower R6g figures cannot be called better efficiency, without holding the realized object set constant or reporting a normalized bytes-per-object measure.

Headroom is the operational result

No node discarded keys to keep operating. The observed throughput is therefore evidence of sustained service with capacity remaining, not behavior after cache churn begins. If this workload represents the application, all three nodes can carry it within the tested hour. The selection can then consider required growth margin, lifecycle and architecture compatibility, regional pricing at purchase time, and performance under the application's next likely load step.

Where this comparison stops

  • Do not claim that a newer CPU generation always produces a faster placement. The two Graviton ranges overlap.
  • Do not convert lower engine CPU directly into an application-capacity claim. The throughput result does not support that shortcut.
  • Do not rank memory efficiency from peak-memory percentage alone when the realized peak key counts differ.
  • Do not turn these results into a current ops-per-dollar recommendation without a fresh regional pricing study.

Where the memory-optimized comparison adds value

The M5, M6g, and M7g analysis observes three generations at a shared memory boundary, where eviction timing changes the meaning of throughput. This R-series comparison supplies the cleaner companion case: the same amount of node memory, the same configured workload, and no eviction phase in any run. The M7g, R7g, and C7gn memory-scaled analysis asks a different question about unlike resource envelopes. Keeping those layers separate prevents a node-family label from being mistaken for a controlled architecture comparison.

Fixed pressure answers a separate question

The fixed-workload runs are close in memory pressure, but not identical. A companion experiment should choose a target utilization before testing, calibrate each node to that target, repeat the same command mix and duration three times, and publish the calibration values with the result. The process in Designing for the Cliff provides the relevant calibration discipline. That follow-up would isolate behavior at similar resource pressure, the table above remains the application-facing result of one unchanged workload on three memory-optimized nodes.

Tags:
Amazon ElastiCache, AWS, valkey, Valkey 9.0, load testing