Zaris vs Redis, measured honestly
Fully measured throughput on Azure over the Redis protocol — 4-core and 8-core clusters to three nodes, every number server-CPU-verified. On production-sized 8-core nodes Zaris beats Redis at every cluster size and pulls further ahead as you add cores. We also show the honest trade-off: Zaris uses more memory. Every figure here is reproducible from the open-source benchmark repo.
Methodology — and full transparency
- Load generatormemtier_benchmark (Docker, host network) for Redis and Zaris-RESP; a custom open-source native-client generator (NativeBench) for the native numbers. Both drive 100-byte values, 1:1 read/write.
- ServersAzure F4als_v6 (4-core) and F8als_v6 (8-core) — current-gen AMD Zen4 — in one VNet. Client load from F16als_v6 (16-core) VMs.
- Fair to RedisRedis is steelmanned:
--io-threads= core count with--io-threads-do-reads, persistence off, and a real Redis Cluster. Load is pinned to each key's owning node so every engine is measured identically. - Stopping ruleWe raise client load until server throughput flattens and node CPU saturates — verified with
mpstat/docker stats, not a fixed client count. A number counts only when the server, not the client, is the limit.
Our honesty rules
- Every throughput number was server-CPU-verified at saturation — no cherry-picked peaks.
- We show where Zaris trails, not just where it wins — including its higher memory use.
- Redis gets its best multi-core configuration, not a hobbled one.
- One workload (100 B, 1:1) on specific Azure SKUs. Yours will differ — run it yourself.
8-core cluster: Zaris beats Redis at every size
Redis-protocol cluster on 8-core nodes, every node's CPU verified saturated at once. Zaris leads at one node (+87%), two nodes (+70%) and three (+81%) — a drop-in replacement, no application changes.
Both scale near-linearly across nodes; Zaris is simply higher per node because it uses every core, where a single Redis instance executes commands on one thread. Zaris's resident memory ran around 0.7–1.4 GiB per node at these loads — mostly GC working memory the runtime holds under write-churn, not live data (per-record overhead is ~2.5× Redis; see Memory below).
Zaris scales with cores. A single Redis instance doesn't.
Redis executes commands on a single thread per node, so adding cores barely moves its ceiling. Zaris's RESP front-end is fully multi-threaded. Double the cores (4→8) on a single node and Zaris nearly doubles (2.89M → 5.56M, 1.9×) while Redis gains little (2.45M → 2.97M, 1.2×). That's why the lead grows from a few percent on 4-core boxes to +87% on 8-core.
On small 4-core nodes the two are close (Zaris 2.89M vs Redis 2.45M). The bigger the box, the wider Zaris's lead — so on the production hardware you'd actually deploy, Zaris wins decisively.
You can match the cores — but not without losing availability
The usual rebuttal: run several Redis instances per box to use all the cores. You can — but each instance owns a slice of the keyspace, so a single machine now hosts multiple shards. When that box goes down, you don't lose one shard, you lose all of them at once — a much larger blast radius, and every one needs its own failover. Zaris uses all the cores in one node with one failure domain and built-in replication, so a node loss is one owner changing hands, not a correlated multi-shard outage.
4-core cluster — measured, for completeness
Even on small 4-core nodes Zaris edges Redis at every cluster size, and both scale near-linearly to three nodes. The margin is modest here; it's the bigger nodes where Zaris pulls away.
Even faster at scale: the native client
The numbers above use the drop-in Redis protocol. Zaris also has its own native binary client that talks straight to the engine. On 8-core nodes it pulls ahead of even the RESP numbers at scale — 11.4M at 2 nodes, 18.5M at 3 — and beats Redis by up to 2.4×.†
† These native numbers use a high-throughput server mode (opt-in, for replication-factor-1 stores) driven by the native .NET client. At a single node it's about level with RESP (~5.0M vs 5.56M); its advantage shows as you scale out. It needs the native client build in the benchmark repo, so we present it as an advanced option rather than the default. The drop-in RESP numbers above need nothing special.
Per-operation latency: no compatibility penalty
Single operation in flight (unloaded), 8-core node. Zaris's Redis-protocol front-end is indistinguishable from Redis on latency — the compatibility layer adds no measurable cost.
Honest note: the native client's per-op latency (~125 µs) is measured with the managed .NET client, while Redis and Zaris-RESP are measured with the C memtier client — so this compares client stacks, not just protocols. The native path's strength is aggregate throughput at scale, not single-op latency.
Memory: the real gap is ~2.5×, not 10×
Same dataset — 1,000,000 keys × 100-byte values (~100 MB raw) on one node. A raw resident snapshot put Zaris at 2.29 GiB against Redis's 222 MiB — but breaking the heap down tells a truer story. Only about 0.5 GiB is live data — roughly 2.5× Redis per record, the cost of a managed (.NET) engine that keeps per-record metadata (labels, entity, content-type, absolute TTL, a replication clock) and ownership structures. The rest is memory the .NET garbage collector has committed but not yet returned to the OS under sustained write-churn (the default server-GC retain posture); a GC heap limit brings the working set back down. So the real per-record gap is about 2–3×, and it's tunable — not the 10× the resident figure suggests. For memory-bound tiny-value workloads Redis is still leaner; Zaris trades some memory for throughput, core-scaling, and built-in HA.
The honest caveats
Memory: ~2.5× per record, not 10×
A raw resident snapshot showed 2.29 GiB vs Redis's 222 MiB for 1M × 100 B — but a heap breakdown puts only ~0.5 GiB of that in live data (~2.5× Redis per record, for metadata + replication). The rest is GC working memory the runtime holds under write-churn, which a GC heap limit brings down. Still weigh it for memory-bound tiny-value workloads.
The native numbers are opt-in
The 11–18M native numbers use an opt-in high-throughput server mode (RF1) plus the native .NET client from the benchmark repo. The drop-in RESP numbers — which already beat Redis — need nothing special.
Native latency is higher
Per single op, the managed native client measures ~125 µs vs ~81–83 µs for Redis/RESP via the C memtier client. That compares client stacks; native’s strength is throughput at scale.
Margin depends on node size
On small 4-core nodes Zaris leads only slightly. The decisive wins (+70–87%) are on production 8-core nodes, because Zaris scales with cores and a single Redis instance does not.
One workload, one cloud
100-byte values, a 1:1 read/write mix, random keys, on specific Azure AMD Zen4 SKUs. Different sizes, ratios, and hardware will move the numbers.
Measure your own
The entire harness — scripts, load generators, methodology — is open source. Reproduce every number on your cluster, node size, and workload, which is the only comparison that matters.
Don't take our word for it — measure it
The whole benchmark harness is open source: the scripts, the load generators, and the exact methodology. Stand up a cluster, run it on your hardware and workload, and compare.