ElastiCache M5 vs M6g vs M7g: Three Generations of General-Purpose Nodes

This is a fixed-workload read of nine one-hour Valkey 9.0 runs on Amazon ElastiCache: three each on cache.m5.large, cache.m6g.large, and cache.m7g.large. All used the same keyspace, command mix, load, and nine-worker client setup, and each node reports 6.38 GiB of memory. The useful question is not simply which median is highest. It is whether moving from M5 to M6g to M7g produces a consistent generational improvement under the same application load.

It does not. The medians order M5, M6g, then M7g, but individual run ranges overlap, practical key capacity barely changes, and each generation enters eviction at a different point in the hour. These are three operating profiles at the same memory boundary, not a monotonic performance ladder.

Fixed-workload evidence across three generations

Ranges cover three runs. First eviction is elapsed time from workload start (mm:ss). M7g had no eviction in one of the three runs.

The median order is not a generational ladder

The surface order is M5 at 53,641 ops/s, M6g at 45,239, and M7g at 42,921. The individual runs do not form three separated performance bands. M7g's best run reached 49,743 ops/s, above M6g's best run at 48,838 and M5's lowest run at 46,123. M6g's best run also exceeded M5's lowest. The median remains a useful summary, but the overlap prevents a claim that the generation label predicts the result of an individual placement.

The practical capacity ceiling barely moved

Peak key count across all nine runs stayed between 3,717,830 and 3,722,566, a spread of roughly 0.13%. Every node reached 99.89% to 100% peak memory. For this key and value distribution, the three generations therefore exposed effectively the same practical capacity ceiling. A newer CPU generation did not create more cache capacity inside the same 6.38 GiB memory envelope.

Lower engine CPU did not become higher served throughput

Reported peak engine CPU ranged from 48.5% to 56.6% on M5 and from 47.1% to 53.2% on M6g. M7g was much lower at 34.8% to 39.8%, yet it did not lead median throughput. That does not prove M7g is intrinsically more efficient: the runs were not in the same eviction phase, and hit behavior differed. It does show that more engine-CPU headroom can coexist with lower served throughput when the overall cache state changes. This data is not a clean CPU-saturation ranking.

Eviction phase changes the shape of the hour

M5 first evicted between 25m 49s and 56m 05s, M6g between 30m 59s and 56m 46s, and M7g between 51m 15s and 58m 59s in two runs. Its third run finished at 99.89% memory without an eviction. The early M5 and M6g runs also had 6.1% and 5.5% average hit rates and accumulated 4.54 million and 3.27 million evictions. Later repetitions had hit rates in the mid-40s to low-50s and reached the cliff much later.

Total evictions are therefore not a memory-efficiency score. A run that spends much of its hour beyond maxmemory is not in the same operating phase as one that crosses the threshold in the final minutes. The timing belongs beside throughput whenever these runs are compared.

Predictability did not improve in a straight line

M6g had the tightest cross-run throughput spread at 4,921 ops/s, and its within-run coefficient of variation stayed between 0.6% and 1.3%. M5 spanned 8,839 ops/s with within-run CV as high as 11.8%, and M7g spanned 7,753 ops/s and reached 10.8%. In this sample, Graviton2 was the most repeatable of the three. Graviton3 did not extend that pattern into a simple generational improvement.

Where the three-generation view adds value

The existing M6g versus M5 analysis asks whether the Graviton2 price advantage comes with a dependable performance tradeoff. It also covers Valkey 7.2, price/performance, and migration choice. This page does not repeat that decision. Adding M7g tests a different hypothesis: whether three general-purpose generations produce a consistent progression in throughput, capacity, engine CPU use, and repeatability. They do not.

Fixed pressure remains a separate experiment

A stricter architecture comparison should calibrate M5, M6g, and M7g to approximately the same target memory utilization before repeating the one-hour protocol. That companion data set must preserve the calibration values and remain separate from this fixed-workload result. The table above answers the application-facing question: what happened when one unchanged workload met each provisioned node?