Zum Hauptinhalt springen
← All videos

In-Memory Search at Scale — a Million Records in Milliseconds

Search a million records in milliseconds on one node — then add a machine and watch it scale.

5 minWatch on YouTube ↗

Watch it, or read it

The full walkthrough below — every screen from the video, with the narration transcribed. Skim it, search it, or read it in your own language.

In-Memory Search at Scale — a Million Records in Milliseconds — screen 1
Search is where data systems slow down. You index your fields, you tune your database, and still — the more rows you hold, the longer every query takes, and the harder it gets to go faster. Zaris takes a different path: indexed search, served entirely from memory, across a cluster that grows with you. In the next five minutes we search a million records, live, on real cloud hardware. And then we make it faster — simply by adding a machine.
In-Memory Search at Scale — a Million Records in Milliseconds — screen 2
Here is the setup. One million customer records, each with the fields you would really search on. Every field indexed — exact matches, numeric ranges, combined filters, prefix search, and ordered top-N. The store runs on real eight-core cloud machines, each with sixteen gigabytes of memory, queried remotely over the network, exactly as an application would. We begin with a single node, then add a second.
In-Memory Search at Scale — a Million Records in Milliseconds — screen 3
Start with the simplest query: find one record by a unique field, across all one million. On a single eight-core node, that search returns in zero point one seven milliseconds — sub-millisecond. And under concurrent load, that one machine sustains around one hundred and forty thousand searches every second. An ordered top-ten over the entire million? Also sub-millisecond.
In-Memory Search at Scale — a Million Records in Milliseconds — screen 4
And you express these queries in plain code. You describe what you want — this entity, this field equals that, this range of ages, order by age, take the top ten — and Zaris serves it straight from its in-memory indexes. No query planner to coax, and no separate search system to keep in sync. The data you write is searchable the instant it lands.
In-Memory Search at Scale — a Million Records in Milliseconds — screen 5
Here is the full single-node run, over a million records. A point lookup and an ordered top-ten, both under a fifth of a millisecond. A combined filter, matching nearly seventy thousand records, in twenty milliseconds. A range scan over two hundred thousand matches, in fifty. Every one of these queries is faster than the same search on a warm, fully-indexed, disk-based database — on a single node. In memory beats disk, even before we scale.
In-Memory Search at Scale — a Million Records in Milliseconds — screen 6
Why is it this fast? The indexes live entirely in memory, so there are no disk seeks on the path of a query. Each node keeps one unified index over its own data, instead of scanning hundreds of little shards. Writes become searchable the moment they are accepted — no export job, no nightly re-index. And a query only ever touches the records that actually match it.
In-Memory Search at Scale — a Million Records in Milliseconds — screen 7
But a single node is the floor, not the ceiling. A disk-based database on one machine is about as fast as it will ever be — to go faster you buy a bigger box. Zaris is different: when you need more, you do not tune harder, you add a machine. So let us add a second node, and run the exact same searches again.
In-Memory Search at Scale — a Million Records in Milliseconds — screen 8
Same filter, same million records, now across two nodes. The work splits: each machine owns half the data and searches its half in parallel. The latency falls — that fifty-millisecond range scan drops to thirty. And the throughput climbs, from one hundred and eleven searches a second to two hundred and seventy. More than double the throughput from one extra machine — better than linear. The heavier the search, the more scaling pays off.
In-Memory Search at Scale — a Million Records in Milliseconds — screen 9
This is the part a single server cannot follow. The scaling unit is a whole machine — add one, and the cluster automatically spreads to use it, with no manual resharding and no downtime. Clients simply pick up the new layout and keep going. Two nodes already beat the single database on every query — latency and throughput — and you add a third, a fourth, and that line keeps climbing.
In-Memory Search at Scale — a Million Records in Milliseconds — screen 10
To recap what we measured, live. A million records, searched in milliseconds. Faster than a tuned, disk-based database, even on a single node. And when you need more, you add a machine — and search gets both faster and higher in throughput. In-memory speed, indexes that are always fresh, and scaling with no ceiling.
In-Memory Search at Scale — a Million Records in Milliseconds — screen 11
This is Clustron Zaris — in-memory search that scales with your cluster. Head to clustron.io to explore the numbers and try it yourself. Thanks for watching.

More videos

Getting Started — a Distributed Cache for .NET in MinutesSecuring a Distributed .NET Cache — Authentication & RBACTLS & Mutual TLS for a Distributed .NET CacheDistributed In-Memory Cache Architecture, ExplainedLinear Scaling Benchmark — 1 → 2 → 3 Nodes, LiveAny Language, One Store — Zaris Speaks RedisDrop-in Redis — Point StackExchange.Redis at ZarisNative Data Structures in .NET — Hashes, Lists, Sets, Sorted SetsRedis Streams, Native — Event Log + Consumer GroupsASP.NET Core Caching Without Redis — IDistributedCache & HybridCacheSurvive a Node Failure — Live HA FailoverElastic Scaling — Add Nodes LivePub/Sub in .NET — Cluster-Wide Messaging
Get startedSubscribe on YouTube