Benchmarks
Real numbers, with the conditions attached.
Every figure below comes from a reproducible run in our benchmark suite. We publish the test conditions next to each number, because a latency figure without its workload is marketing, not measurement.
Latency — single user, full HTTP stack
Apples-to-apples against a dedicated vector database: one user, one worker, 1024-dimensional embeddings, over the full HTTP stack — with the graph engine, write-ahead log, AES-256-GCM encryption, and RBAC all running in the same process at the same time.
1 user · 1 worker · 1024d · full HTTP + auth + durable write log + encryption + RBAC. Single-user, not under concurrent load.
100K corpus · 1024d · in-process, no HTTP or serialization overhead.
Throughput — ingest & concurrent load
Sustained write and query throughput, from batch ingestion to hundreds of concurrent users.
batch-1000 · 128d · direct engine. Single-node ingest P95 is 4 ms.
500 users · 32 workers · 384d · 5 min · full HTTP stack. 0 gate failures.
500 users · 32 workers · 30-min soak. 3 × HTTP 500 in 1.28M requests (0.0002%) — transport-layer timeouts, not engine errors. Zero data corruption or incorrect results.
Memory — bounded by hardware, not corpus
Purple8 fits its ingest footprint to the RAM available. A hardware-aware auto-configuration sizes the batch geometry so peak memory tracks the machine, not the amount of data. Peak memory usage stays within a fixed envelope as batches complete and are evicted — it does not grow with total corpus size.
8.84M-passage corpus · Apple M-series 24 GB. Peak memory held around 9 GB in a stable bounded envelope — never grew with corpus size. No swap required.
Peak memory is set by available RAM, not corpus size. A smaller machine ingests the same corpus in more time — the memory envelope stays hardware-bounded.
Footprint — you start ahead
The consolidated stack removes the overhead a 29-service architecture pays just to stand up — before a single record is stored. Idle draw is runtime tax, inter-service network buffers, duplicated caches, and connection pools; Purple8 has one runtime, one cache, one pool.
One process up and ready before any data is ingested — one runtime, one thread pool, one cache. Data is streamed from disk behind a bounded window, so the footprint is set by the machine, not the corpus.
Overhead reserved before any data is stored, even at a charitable 50 MB runtime floor per service: ~1.45 GB runtimes + inter-service network buffers + the same rows cached 3–5× + per-service connection pools. Structural estimate of a minimal production stack, not a single measured deployment.
Methodology
- Instance
- AWS c6i.metal — 128 vCPU, 251 GB RAM, x86_64, Ubuntu 24.04
- Engine
- Purple8 v0.61.0 · Cortex storage
- Suite
- purple8-graph benchmarks/ suite
- Last run
- July 2026
Latency figures marked as single-user are not measured under concurrent load. Direct-engine figures exclude HTTP, auth, and serialization overhead. Memory behavior is bounded by available RAM via hardware-aware auto-config; a fixed-corpus deployment reaches steady state once index pages are warm. v0.61.0 is the purple8-hyper-graph package version (pyproject.toml). The HTTP API version field in responses reflects the API revision, not the package version.