Fast because of where it runs
In-memory, in-process or a hop away — partitioned for parallelism, with a low-allocation hot path and bulk operations that amortize the network. And it's all measurable, live, from the console.
Speed from the design, not a benchmark trick
The performance comes from where the data sits and how requests reach it — the same properties hold whether you run embedded or clustered.
In-memory
Data lives in RAM, not on disk. Reads and writes never wait on storage I/O — durability comes from replication, not fsync.
In-process option
Run embedded and there is no network hop at all — calls are method calls. The same code moves to a cluster when you need one.
Partitioned parallelism
Keys are spread across partitions and nodes, so throughput scales with the cluster — add nodes, the map grows onto them.
Low-allocation hot path
Built-in metrics meter the hot path with minimal allocation, and the client pools connections — overhead stays off your latency budget.
Bulk & batch ops
PutMany / GetMany and mixed batches collapse many keys into one round trip per owner, amortizing network cost.
Async replication
With async replication a write acknowledges without waiting for every replica; choose sync + quorum when you want stronger guarantees.
Watch it move, live
Zaris is built for very high throughput at sub-millisecond latency — and the numbers scale with your hardware, so the ones that matter are yours. The console streams throughput, replication and latency in real time, and the built-in benchmark lets you measure it on your own cluster.
- Live ops/sec, replication and derived latency in the console
- Built-in Benchmark to load-test your real cluster
- Export everything over OTLP to the stack you already run
Trade latency and durability, per store
The same store can favor raw speed or stronger guarantees — the knobs are configuration, not a rewrite.
Replication mode
Async for lowest write latency; Sync with a quorum (All / Majority) when a write must be durable on replicas before it returns.
Replication factor
Higher RF means more availability but more replication work per write. RF2 tolerates one node loss; pick per store.
Client connections & failover
The client pools connections and fails over across the seed list, then routes each key straight to its owner — no proxy hop.
TTL & eviction
Bounded memory with TTL and eviction under a ceiling keeps the working set hot without unbounded growth.
See it move — in your own cluster
Stand up a store, run the built-in benchmark, and watch the numbers live. Then tune it to your workload.