Zaris does indexed, SQL-style search over the data it already holds in memory — exact match, ranges, filters, prefix, and ordered top-N. A million records searched in milliseconds, faster than a warm, fully-indexed disk-based database on a single node — and it scales with every node you add.
A point lookup or an ordered top-N over a million records returns in under 0.2 ms — about 140,000 searches a second on a single eight-core node. Served from in-memory indexes, with no disk on the query path.
A combined filter matching tens of thousands of records returns in ~20 ms; a range scan over two hundred thousand matches in ~50 ms — every query faster than the same search on a warm, fully-indexed, disk-based database.
Writes are searchable the instant they are accepted. There is no export job, no nightly re-index, and no second search system to keep in sync with your data.
Each node owns half the data and searches its half in parallel, so a filtered search over a million records drops from ~50 ms to ~30 and its throughput more than doubles — better than linear — from one extra machine.
Add a node and the cluster automatically spreads to use it. Clients pick up the new layout and keep going — there is no manual resharding and no pause in service.
A single disk-based database node is about as fast as it will ever be. Two Zaris nodes beat it on every query — latency and throughput — and the line keeps climbing as you add machines.
Describe what you want — this entity, this field equals that, this range, order by, take the top N — with SearchQuery.For(...).Eq(...).Range(...).OrderBy(...).Limit(...), and read back keys or whole records.
Store records with indexed labels and Zaris builds per-node equality, range, and prefix indexes automatically — exact match, ranges, combined filters, prefix, and ordered top-N, all served from the index.
Searches run straight off in-memory indexes, not a full scan — and there is no separate search engine to deploy, feed, and operate alongside your store.
The data you cache is the data you search — one store, one connection string, partitioned and replicated for availability. No cache-plus-search-index to wire up and keep consistent.
Run the store embedded in your app for local dev and tests, then point the same client code at a real remote cluster — the move is a configuration change, not a rewrite.
Every number here is measured live on real cloud hardware and reproducible from the open-source benchmark suite — the only comparison that really counts is the one on your data.
The data you cache is the data you search — in memory, always fresh, and scaling with your cluster.