Skip to main content
Search, vectors, graph, blobs, metrics and an archive tier, each store built for one job. Watch which one saturates first, and which fails without a sound.

What to watch

One general purpose database would do all of this badly. A text index, a vector index and a graph each answer a question the others are slow at, and the price is four stores to run instead of one. Take the load to 4x. The vector index saturates and the client sees the errors immediately. The archive path saturates too and says nothing: the batch client is still acked while cold storage sheds behind the queue. Cold storage is slow on purpose, seconds per restore, because almost nothing is ever read back. Paying for fast storage you never read is the mistake this avoids.

What it is made of

Under load

Measured by running this design through the simulator at multiples of its own offered rate of 246 requests a second. Twenty seconds of simulated time, one fixed seed, so the same numbers come out every time.
This design holds 738 requests a second with 0% errors. At 984 it is losing 8% of them.

Open this example

Load Specialised stores from the Examples menu and drag the traffic slider yourself.