Testing · evidence · limitations
Memory and expiration
Memory is reported as a measured resident-set delta or plateau, not a promise that process RSS immediately falls when keys expire.
Native Redis memory comparison · 2026-10-07
Environment: fresh native processes on Apple M4 Pro, 12 cores, 24 GiB, macOS 26.6.2 arm64; Ruvio 0.2.10 release rebuilt from 203f4fc plus uncommitted TTL deadline-index accounting changes, one shard with memory durability; Redis 8.10.2 with persistence disabled. The Ruvio build is not identifiable by the commit alone. Both servers are bound to loopback and run separately. These memory results accompany the 17-command speed comparison.
One million distinct strings
Method: one connection, pipeline 200, one million unique keys (k0…k999999) with 64-byte values. Every SET response and the final DBSIZE were verified before sampling ps process RSS. Idle and loaded values come from each fresh process; the delta subtracts its own idle RSS.
| Process RSS | Ruvio | Redis 8.10.2 |
|---|---|---|
| Idle | 9,440 KiB | 7,104 KiB |
| Loaded | 94,368 KiB | 139,408 KiB |
| Loaded − idle | 82.9 MiB | 129.2 MiB |
| Ruvio / Redis delta | 0.64× | — |
Limit: one key/value distribution on one machine, with one idle and one loaded RSS sample per process. The string-load advantage does not establish a general memory advantage for other data types, large keyspaces or long-running workloads.
Equal-work connection and data churn
Method: fresh processes, 2,500 passes per engine with a 10 ms pause between passes. Each data pass performs a SET/GET and 64 SET/DEL pairs; full additionally reconnects and sends an unread 20,000-PING burst while checking that another connection remains responsive. data holds one connection and excludes those bursts. Engines ran sequentially, not concurrently. Workload peak RSS was sampled every 50 ms; the post-flush reading is one second after FLUSHALL. RSS increases below are relative to each process's own idle RSS.
| Mode, 2,500 passes each | Time Ruvio / Redis | Peak increase Ruvio / Redis | After FLUSHALL Ruvio / Redis |
|---|---|---|---|
| Full (including reconnects and unread responses) | 39.167 / 38.359 s | +1.094 / +0.297 MiB | +1.188 / +0.438 MiB |
| Data only | 35.922 / 36.174 s | +0.297 / +0.234 MiB | +0.391 / +0.375 MiB |
Interpretation: the mixed connection/slow-client probe leaves more RSS above baseline on Ruvio than on Redis; the data-only runs are closer. Ruvio reports zero charged live bytes after FLUSHALL, but process RSS remains above baseline. That does not prove a leak or identify the retained memory. The two products' INFO memory counters are defined differently and are not used for this comparison. Limit: the peak sampler can miss shorter spikes, the unread burst is not sustained backpressure, and these ~36–39 s single-host runs are not a long-running memory bound or cross-platform result.
String-load and throughput samples (JSON) Full-churn samples (JSON) Data-only samples (JSON)
One million live strings · 2026-10-04
Goal: measure space for distinct keys rather than a repeatedly overwritten hot key. Environment: fresh native Apple M4 Pro processes; Ruvio one shard, memory, Redis 8.10.2 with persistence disabled. Method: one connection, pipeline 200, one million explicit k0…k999999 keys and 64-byte values; ps RSS after load minus idle RSS. Result: Ruvio +82.8 MiB; Redis +129.2 MiB (Ruvio/Redis 0.64×). Limit: one key/value distribution, one machine, one measured RSS sample per process; not a long-running memory bound.
Four-core mixed-key soak · 2026-09-28
Method: a historical 15-minute Cherry EPYC run with four shards and four Redis processes, a warm one-million-key range per shard, and SET/GET/INCR at pipeline 16. Result: Ruvio RSS plateau 2.78 GiB versus Redis 648 MiB (about 4.4×). This older, different key mix exposed a memory-density issue. Subsequent one-million-string Docker probes measured much lower Ruvio RSS after layout changes, but the original four-shard mixed-key soak has not been repeated. Do not compare its ratio directly with the newer single-shard string result.
Density investigation and remaining verification
TTL burst and idle drain · local diagnostic
Method: one shard, 20k long-lived keys, a 10-second burst of 50k SET PX 1200/s, everysec WAL, command sweep 16, 25 ms timer with a 750 µs soft limit. Tested timer batches 16/32/64 on fresh processes. Result: all 500k offered writes were acknowledged per run. Physical keys returned to the 20k baseline in 4–7 s (16), 7 s (32), and 6–7 s (64) without idle PING. Larger batches showed no repeatable drain gain; defaults remain 16/16. Limit: short local macOS runs; the 750 µs limit is checked between batches, not a hard latency bound. The underlying JSONL is session-local, not a published raw dataset: treat this as diagnostic evidence, not a certified capacity figure.