Testing · evidence · limitations
Performance and scale
Measured throughput is specific to workload, durability, key shape, client concurrency and hardware. No number here is a universal capacity guarantee.
17-command Redis comparison · 2026-10-07
Goal: compare native throughput across common commands, including list, set, hash and sorted-set operations. Environment: Apple M4 Pro, 12 cores, 24 GiB, macOS 26.6.2 arm64; native Ruvio 0.2.10 release rebuilt from 203f4fc plus uncommitted TTL deadline-index accounting changes; Redis 8.10.2. Both are separate loopback processes: Ruvio one shard with memory durability; Redis RDB and AOF disabled. This build is not identifiable by the commit alone.
Method: redis-benchmark, 50 clients, pipeline 16, 64-byte values, three rounds per command with alternating measurement order. Each server stays running across rounds; the table reports median requests/s. Most commands ran 1,000,000 requests per round; LRANGE 100/300/500/600 ran 200k/100k/60k/50k, and MSET ran 500k. LLEN verified that both servers' LRANGE reads used nonempty lists (200k/300k/360k/410k elements in round one). The full comparison, including a separate string-memory load, took 75.8 s.
| Command | Ruvio median req/s | Redis median req/s | Ruvio / Redis |
|---|---|---|---|
| PING (bulk) | 2.67M | 2.67M | 1.00× |
| SET | 2.61M | 2.16M | 1.21× |
| GET | 2.74M | 2.38M | 1.15× |
| INCR | 2.88M | 2.57M | 1.12× |
| LPUSH | 2.18M | 1.79M | 1.22× |
| RPUSH | 2.21M | 1.88M | 1.17× |
| LPOP | 2.02M | 1.74M | 1.16× |
| RPOP | 2.03M | 1.80M | 1.13× |
| SADD | 2.28M | 2.35M | 0.97× |
| HSET | 2.17M | 1.82M | 1.19× |
| SPOP | 2.51M | 2.77M | 0.91× |
| ZADD | 2.30M | 1.88M | 1.22× |
| LRANGE 100 | 0.22M | 0.22M | 1.00× |
| LRANGE 300 | 0.08M | 0.07M | 1.04× |
| LRANGE 500 | 0.04M | 0.04M | 1.03× |
| LRANGE 600 | 0.04M | 0.03M | 1.15× |
| MSET | 1.40M | 0.43M | 3.27× |
Interpretation: Ruvio leads SET, GET, INCR and MSET in this workload; Redis leads SADD and SPOP, with SADD inside the approximate ±10% host-variation tie band. Ratios use unrounded rates. Limit: mostly fixed-key pipelined loopback throughput is not production throughput, tail latency, durability throughput, TTL churn or a many-key scaling test. These are three local rounds on one unpinned machine, not confidence intervals. See the separate memory and churn results for the same build.
Full per-round data and environment (JSON)
Native command comparison · 2026-10-04
Goal: compare common command throughput with Redis 8.10.2. Environment: Apple M4 Pro, macOS arm64, native release binary of 1d7e691 with the measured hot-path changes, one shard, memory durability, loopback; Redis persistence disabled. Method: redis-benchmark, 50 clients, pipeline 16, 64-byte values, three rounds on the same fresh pair of servers, alternating measurement order. Most commands used one million requests; key distribution and counts vary by command.
| Command | Ruvio median | Redis median | Interpretation |
|---|---|---|---|
| SET | 2.73M/s | 2.17M/s | 1.26× on this workload |
| GET | 2.90M/s | 2.65M/s | 1.09×; within the host's ±10% tie band |
| INCR | 2.99M/s | 2.51M/s | 1.19× on this workload |
| SPOP | 2.56M/s | 2.65M/s | Ruvio 0.97×; within the tie band |
Limit: pipelined fixed-key loopback results are not networked production throughput, tail latency, TTL churn, or durability throughput. The 2026-10-01 LRANGE measurements likely read an empty list; this 2026-10-04 run checks LLEN after each list read. Reproduce with cargo build --release --bin ruvio and python3 scripts/redis_compare.py --out target/redis-compare.
Full matrix and method Reproduction guide
Four-core bare-metal baseline · 2026-09-28
Environment: pinned Cherry EPYC 7313P Ubuntu host, four Ruvio shards versus four Redis 8.10.2 processes, both memory durability, 25 clients and 500k requests per shard, pipeline 16, 64 bytes; five matrix samples. Result: aggregate SET medians 3.05M/s versus 2.49M/s; GET 3.21M/s versus 3.26M/s. Limit: historical pre-WAL-change build, not today's binary or a Redis Cluster comparison. Multi-shard p99 is the slowest shard, not an aggregate latency percentile.