Valkey 9.0 on ElastiCache t3.small: What Three One-Hour Runs Actually Agree On
Three-run result table
Throughput is a range, not a capacity figure
The June 3 execution leads at 13,663.6 average ops/s. The June 7 execution is lowest at 9,133.3 ops/s, while the May 28 result sits between them at 10,628.8 ops/s. Peak throughput also varies, from 11,229.0 to 19,815.0 ops/s.
Within each run, throughput remains comparatively controlled: CV ranges from 8.45% to 12.26%. The larger variation appears between the completed executions. A result can therefore be steady inside its own reporting window without establishing a repeatable capacity ceiling across runs.
For this workload, the three results establish an observed operating range. They do not support using one average or peak value as a production sizing target or service-level objective.
What the three runs agree on
The throughput numbers differ, but the memory state does not:
- Every run reaches 100% memory.
- Every run records evictions.
- Peak key count remains close to 797,000 keys.
- CPU-credit balance remains near the floor.
The eviction totals vary from 43,497 to 201,562, and hit rate ranges from 44.32% to 57.54%. Those differences describe how the saturated cache behaves in each execution. They do not change the shared conclusion: the tested working set does not fit comfortably within the available memory.
This is a saturation result, not a Valkey limit
The results should not be read as a fixed throughput limit for Valkey 9.0. They show that this combination of node memory and workload reaches maxmemory on cache.t3.small and continues operating in eviction territory.
Once the cache is full, throughput is observed alongside changing hit rate and eviction work. The resulting ops/s values remain useful for comparing executions of the same harness, but they no longer describe clean, eviction-free capacity.
The June 7 raw benchmark is the lowest-throughput result in the set. It averages 9,133.3 ops/s, records 43,497 evictions, and reports its first positive eviction datapoint at 2026-06-07 12:41:00 UTC. Its throughput number is meaningful only alongside that memory state.
CPU credits describe the operating condition
Minimum CPU-credit balances are 0.04, 0.02, and 0.03. The runs therefore describe sustained operation with almost no burst reserve, not an initial credit-rich burst.
That does not make CPU the demonstrated bottleneck. Average engine CPU ranges from 17.82% to 19.65%, with peaks from 22.52% to 30.15%. The measurements do not show CPU saturation or a credit-depletion event that explains the throughput spread.
Memory remains the clearer limiting condition: all three executions reach maxmemory and record evictions, while engine CPU stays well below full utilization.
Low latency does not mean the working set fits
Average benchmark latency ranges from 0.437 to 0.654 ms, while p99 ranges from 0.439 to 0.677 ms. These are low client-observed values, but they are measured while the cache is full and evicting keys.
Latency and memory pressure answer different questions. The latency result shows that requests remain fast during these executions. The eviction result shows that the node is not retaining the complete working set.
The companion client-latency analysis provides the detailed load-generator-side view for the June 7 execution.
Architecture reading
The practical conclusion is conservative: do not size a production cache.t3.small deployment from the best observed throughput in this set. Start with an operating state that preserves memory headroom and the intended cache contents without sustained evictions.
Where this fits in the broader comparison
This analysis is narrower than the T3 versus T4g comparison across micro, small, and medium. That page compares instance families and sizes under one workload. This page asks whether repeated cache.t3.small executions support the same architectural conclusion.
They do at the operating-state level: memory saturation and evictions repeat. They do not at the headline-number level: throughput, hit rate, and eviction volume vary too much to reduce the result to one representative figure.
Methodology
The comparison uses three separate Valkey 9.0 executions against single-node, non-cluster cache.t3.small Amazon ElastiCache replication groups, with three load-generator tasks in each run.
- 2026-05-28 benchmark report: 2026-05-28 05:25:50.510 UTC to 2026-05-28 06:25:22.366 UTC.
- 2026-06-03 benchmark report: 2026-06-03 18:52:22.261 UTC to 2026-06-03 19:53:43.023 UTC.
- 2026-06-07 benchmark report: 2026-06-07 11:47:08.043 UTC to 2026-06-07 12:47:42.437 UTC.
Throughput and latency come from the memtier_benchmark artifacts. Memory usage, hit rate, evictions, engine CPU, and CPU-credit balance come from the corresponding Amazon ElastiCache and CloudWatch observations.
These are measurements from this test harness, not vendor capacity guarantees. Results can change with data size, command mix, pipelining, connection count, cache-hit behaviour, region, and other deployment conditions.