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.

High-Scale Graph Traversal - up to 20M Nodes / 30M Edges (50M Objects)

Verified on a single 16-vCPU cloud instance (Fly.io performance-16x) scaling up to 20,000,000 nodes and 30,000,000 edges (50M total graph objects in 25.35 GB on NVMe), including power-law super-hub stress tests with millions of incident edges on a single node.

52 µs / 1.26 ms

Point node lookup (P50 / P99)

16 vCPU · cold-slab mmap lookup across multi-million-node graph · 52.0 µs P50, 1.26 ms P99.

0.38 ms / 0.87 ms

2-hop neighbourhood walk (P50 / P99)

16 vCPU · 2-hop graph traversal returning connected subgraph in sub-millisecond P99; guarded super-hub walk completes in 53.1 ms P50 / 58.8 ms P99 with 0 errors.

4,181 QPS

Concurrent 16-thread graph reads

16 concurrent reader threads · 0.44 ms P50 / 13.8 ms P99 latency; 20M nodes + 30M edges stored in 25.35 GB on NVMe.

Multi-User, Multi-Tenant & Concurrent Workloads (v0.72.0)

Measured on Purple8 v0.72.0 across 16 dedicated vCPUs (Fly.io performance-16x), validating concurrent multi-thread graph reads, 16-tenant cryptographic isolation, mixed read/write/traversal/vector storms, and parallel DocIntel document-to-graph commits.

4,858 QPS

16-thread peak concurrent graph reads

v0.72.0 · 16 concurrent reader threads · 1.25 ms P50 / 9.73 ms P99 latency at 2.5M graph objects; sustains 4,181 QPS at 40M graph objects (0.44 ms P50).

1,900 ops/s

16-tenant concurrent isolation (0 leaks)

v0.72.0 · 16 concurrent tenants executing 1,600 simultaneous isolated operations with 0 cross-tenant data leakage.

238 QPS · 2.4 ms P50

16-thread mixed read/write/traversal/vector storm

v0.72.0 · 16 threads simultaneously running point lookups, 2-hop graph walks, vector search, full-text search, and live writes with 0 errors.

200 QPS

16-thread concurrent vector search (384d)

v0.72.0 · 1,600 concurrent vector searches across 16 threads (single-query 4.52 ms P50 / 6.09 ms P95 / 7.63 ms P99).

353 pages/s

DocIntel 8-worker parallel document parsing

v0.72.0 · 35.34 docs/s (10-page enterprise filings) + 70.7 tables/s across 8 concurrent CPU workers (13.2 ms parse P50).

25,596 docs/hr

Coupled DocIntel -> Hyper Graph atomic commits

v0.72.0 · 7.11 full 10-page documents/s (442.4 nodes/s + 619.4 edges/s + tables + chunks) committed atomically (141.8 ms P50, 0.65 ms P50 table row lookup).

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.

23 ms

P95 vector search (k=10)

1 user · 1 worker · 1024d · full HTTP + auth + durable write log + encryption + RBAC. Single-user, not under concurrent load.

1.1 ms

P95 vector search - direct engine

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.

57,000 docs/s

Batch ingest throughput

batch-1000 · 128d · direct engine. Single-node ingest P95 is 4 ms.

752 req/s

Sustained under 500 users

500 users · 32 workers · 384d · 5 min · full HTTP stack. 0 gate failures.

1,283,494

Requests in 30 min · 0 engine faults

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.

~9 GB peak

8.84M passages on a 24 GB machine

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.

same footprint

2M or 20M records

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.

~350 MiB

Purple8 runtime, idle

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.

9–15 GB

29-service stack, idle

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) & Fly.io performance-16x (16 vCPU, 60 GB NVMe, up to 20M nodes / 30M edges)
Engine: Purple8 v0.72.0 · Cortex storage · 14,500+ automated tests
Suite: purple8-graph benchmarks/ suite
Last run: 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.72.0 is the purple8-hyper-graph release version.