CACHEARENAHosted by

Redis-compatible systems / published benchmarks

Cache performance.
In context.

Compare Redis-compatible systems, from in-memory controls to billion-key storage tiers. See the numbers, the setup, and the tradeoffs.

How we measure/View source reports
02source reports
03comparison cohorts
146connection-sweep measurements

First edition · vendor-published data

A note on ownership

CacheArena is owned by Lavik. These initial results were measured and published by Lavik, and have not been independently replicated.

Our approach to fairness

01 / Explore the results

Different workloads. Different answers.

Choose a comparable test cohort.
16 logical CPUs · same host1 KiB values30 seconds / point

Lavik: values on NVMe SSD. Redis and Valkey: values in DRAM. Lavik still uses DRAM for its key index and runtime state.

10M keys / Read-only GET

Throughput by system

ops/secHigher is better

Each row shows that system’s highest measured throughput; connection counts can differ. QPS is rounded for display; the CSV preserves source precision.

Value-capacity cost / illustration

A different storage medium.
A different cost equation.

1/20of Redis value-capacity cost
at a 20:1 DRAM / NVMe SSD price ratio

Lavik places values on NVMe SSD while Redis and Valkey use DRAM. This model illustrates the storage economics alongside the measured throughput above.

Lavik’s cost methodology

Relative value-capacity cost · Redis = 100%

LavikNVMe SSD
5%
RedisDRAM
100%
ValkeyDRAM · memory-use example
80%

Lavik’s 5% assumes DRAM costs 20× more per GiB than NVMe SSD. Index memory, runtime memory, replication, and shared server costs are additional. Valkey’s 80% follows the separate 400 GB vs 500 GB memory-use example linked on Lavik’s homepage, at equal DRAM prices. These are not measured costs for the 10M-key benchmark or whole-deployment savings.

The numbers behind the chart

3 configurations · 10M keys
10M keys · NVMe SSD vs DRAM, Read-only GET. Sorted by Throughput.
System / versionThroughput ops/secp99 msp99.9 msConnectionsServer threads¹Evidence
LLavikSPDK · NVMe SSD0.1.0-beta.11,012,1803.5995.63164016 workersSource report
RRedisDRAM8.8.0976,8014.6718.0311,28016 io-threadsReused control
VValkeyDRAM9.1.0965,6974.5438.1591,28016 io-threadsReused control

Redis and Valkey use their best measured I/O-thread configuration for the selected workload by default. AOF and automatic snapshots are disabled. Thread roles and persistence semantics differ. Read the test conditions

¹ Thread counts describe different roles, not equivalent compute. Garnet’s actual thread count is not fixed. All 10M- and 1B-key server processes share a 16-logical-CPU affinity limit.

Inspect the full connection sweepEvery measured point for the selected thread configurations

Throughput across client connections. The vertical scale starts at zero. Each point is one run.

0273k547k820k1.09M801603206401280Lavik: 390,494.48 ops/sec at 80 connectionsLavik: 609,160.94 ops/sec at 160 connectionsLavik: 803,016.34 ops/sec at 320 connectionsLavik: 1,012,179.91 ops/sec at 640 connectionsLavik: 940,713.30 ops/sec at 1280 connectionsRedis: 424,582.46 ops/sec at 80 connectionsRedis: 574,701.86 ops/sec at 160 connectionsRedis: 769,130.32 ops/sec at 320 connectionsRedis: 919,798.51 ops/sec at 640 connectionsRedis: 976,800.89 ops/sec at 1280 connectionsValkey: 544,238.03 ops/sec at 80 connectionsValkey: 692,905.05 ops/sec at 160 connectionsValkey: 826,689.24 ops/sec at 320 connectionsValkey: 897,768.48 ops/sec at 640 connectionsValkey: 965,696.86 ops/sec at 1280 connections
Lavik SPDK · NVMe SSDRedis DRAMValkey DRAM
Exact throughput values (ops/sec)
System80 conn.160 conn.320 conn.640 conn.1280 conn.
Lavik SPDK · NVMe SSD390,494.48609,160.94803,016.341,012,179.91940,713.30
Redis DRAM424,582.46574,701.86769,130.32919,798.51976,800.89
Valkey DRAM544,238.03692,905.05826,689.24897,768.48965,696.86

02 / Read beyond the ranking

A result is only as useful as its context.

01

Throughput and latency

A high peak QPS does not guarantee lower tail latency. Compare p99 and p99.9 at the same connection count to understand that tradeoff.

Compare write latency
02

Same host, different paths

CPU affinity is shared; storage engines, RAM budgets, warmup, and persistence are not identical. Those differences are part of each result.

Inspect the environment
03

Evidence you can inspect

The 10M- and 1B-key report includes every connection-sweep point, commands, binary identities, and a checksummed evidence archive.

Explore the source data

03 / Behind the benchmark

Open about the data.
Open about the limitations.

We want these results to be useful even when Lavik is not the best fit. Every system follows the same display and ranking rules.

Read the methodology
  1. 01

    Keep the experiments separate

    No overall winner across different datasets or hardware.

  2. 02

    Show the measurement behind the claim

    Versions, connections, latency, and source links stay visible.

  3. 03

    Make uncertainty visible

    Single runs are observations, not statistical proof.

Questions, answered

Before you use these numbers.

Is CacheArena independent?

No. CacheArena is owned by Lavik, and this first release presents Lavik-authored measurements. Publishing configurations and evidence supports scrutiny; it does not remove the conflict of interest.

Can I compare results across the three cohorts?

No. Dataset sizes, hardware, storage paths, software versions, and test durations differ. Comparisons are confined to one cohort and workload. The managed Azure experiment is separate too.

How do I reproduce or challenge a result?

Use the pinned source reports and the SPDK benchmark evidence archive for the exact configurations. Their acquisition scripts are host-specific and include destructive scratch-disk preparation: adapt them only to verified disposable test hardware. Open an issue with the workload, version, configuration, and evidence.