System Requirements

Release: Purple8 Hyper Graph v0.72.0 (pip install purple8-hyper-graph)

Hardware, accelerator, and OS requirements for Purple8 Hyper Graph, with practical data-size context to help you right-size your deployment. Purple8 is an embedded, in-process multi-model engine (pip install purple8-hyper-graph or Docker / Red Hat OpenShift UBI9) — the same GraphEngine / BrickCoreStorage (Purple8 Cortex) binary runs at every scale.

Purple8 is an approved Red Hat Technology Partner and NVIDIA Inception program member.

Self-Hosted Tiers at a Glance

Purple8 offers two self-hosted tiers (see Pricing):

Tier	Price	Node Limit	MCP Agents	Best For
Developer (Self-Hosted Free)	$0	Up to 50K nodes	1 MCP agent	Full local engine for development, prototyping, and evaluation
Enterprise / Custom (Self-Hosted)	Custom	Tailored to customer capacity	Unlimited / Custom	Commercial self-hosted deployments — tailored to customer capacity, cluster topology, HA, and SLA

---

Storage Engine & Bounded Memory Model (BrickCoreStorage + CortexAutoConfig)

GraphEngine is backed by BrickCoreStorage (Purple8 Cortex) with BrickWAL (fdatasync before mutation) and CortexAutoConfig (GraphEngine(..., auto_config=True)).

Never project RAM by multiplying per-node size by N

In legacy graph or vector databases, memory grows linearly with total node count N. In Purple8 Hyper Graph, peak process RSS does NOT grow monotonically with corpus size N. Never estimate RAM by multiplying per-node size by N.

The Brick Seal-and-Evict Cycle

1. The lock-free Rust DashMap write buffer fills for one batch (batch_size nodes) — RSS rises within the configured budget.
2. BrickWAL.append_batch() seals the batch with a single os.write() + single fdatasync().
3. Completed DashMap entries are evicted and pages are returned to the OS — RSS drops back to baseline.
4. The next batch begins inside the exact same fixed memory envelope, regardless of how many millions of nodes have already been ingested.

At startup, CortexAutoConfig probes available RAM and derives (M, ef_construction, segment_size, batch_size) so that peak process RSS never exceeds alpha * available_ram (default alpha = 0.75). On a constrained machine, batch_size is reduced: ingestion takes longer, but always completes within the hardware memory envelope.

Validated benchmark proof (8.84M MS MARCO corpus, 384-dim, 24 GB machine):

• Ingest peak RSS: ~9 GB (sawtooth across all 90 seal cycles — never grew with N)
• Query-time steady-state RSS: ~5.4 GB (3,626 MB returned to the OS after ingest completed)

---

Hardware & Accelerator Auto-Discovery

At startup, CortexAutoConfig (purple8_graph.core.auto_config) and worker_solver.py (purple8_graph.core.worker_solver) automatically inspect the host's CPU, NUMA, and GPU/XPU topology:

Hardware Dimension	What Purple8 Auto-Detects	How Purple8 Uses It
Multi-Socket CPU & NUMA	Physical CPU sockets (cpu_sockets) and NUMA nodes (numa_nodes)	Computes recommended_shards = max(cpu_sockets, numa_nodes) for NUMA-local shard and Rayon thread-pool pinning
Intel AMX & Intel XPU	Intel AMX tile instructions (amx_tile, amx_int8, amx_bf16) & Intel XPU (torch.xpu integrated/discrete Arc & Data Center GPU Max)	Accelerates matrix/vector distance kernels and routes local embedding/inference workloads to Intel XPU
NVIDIA Tensor Core GPUs	NVIDIA Hopper (H100 / H200, sm_90) and NVIDIA Blackwell Ultra B300 / GB300 (288 GB HBM3e, sm_103, FP4 Tensor Cores)	Sizes high-throughput batch geometry, FP4/FP8 Tensor Core inference, and GPU-accelerated vector workloads
Apple Silicon Metal	Apple M-series Unified Memory (mps)	Zero-copy unified RAM allocation across BrickCoreStorage and local LLM/embedding inference

---

Developer Tier (Self-Hosted Free — up to 50K nodes, 1 MCP agent)

Runs identically via pip install purple8-hyper-graph or a single Docker / Podman container on a laptop, workstation, or small VM.

Recommended hardware (Developer)

Component	Minimum	Recommended
CPU	2 cores	4 cores
RAM	4 GB	8–16 GB
Disk	10 GB SSD	25–50 GB NVMe SSD
OS	macOS 13+, Linux (Ubuntu 22.04+, RHEL 9 / UBI9), Windows (WSL2)	Linux or macOS
Python	3.12	3.12

---

Enterprise / Custom Tier (Self-Hosted Production — Single-Node to Multi-Shard HA)

The single commercial self-hosted tier covers everything from a single production server (millions of nodes) to multi-socket NUMA hosts, primary/replica HA pairs, and multi-shard Raft clusters with SuperGraph federation.

What fits?

Deployment Profile	Nodes	Edges	Architecture	Typical Workload
Departmental / Single-Instance Production	1M–50M	4M–200M	Single primary + optional WAL replica (WORKERS=1)	Enterprise RAG, AML detection, AEC/BIM analysis, Journey workflows
Multi-Socket / NUMA Scale-Up	50M–200M	200M–800M	recommended_shards = max(cpu_sockets, numa_nodes)	High-throughput enterprise knowledge graph + SOC
Sharded Cluster with Raft HA	100M–1B+	400M–4B+	3–16 shards × 3-node Raft quorum	Global financial crime, hyperscale knowledge graph, cross-region SuperGraph

Recommended hardware — Enterprise Single-Instance / Primary-Replica

Component	Production Baseline (384–768d)	High-Throughput / 1536–3072d
CPU	8 cores	16–32 cores (AVX2 / Intel AMX / ARM64 Neoverse)
RAM	16–32 GB (bounded by CortexAutoConfig)	32–64 GB (bounded by CortexAutoConfig)
Disk	200 GB NVMe SSD	500 GB–2 TB NVMe SSD
OS	RHEL 9 / Red Hat OpenShift (UBI9 Dockerfile.rhel) or Ubuntu 22.04+	RHEL 9 / OpenShift or Ubuntu 22.04+
Network	1–10 GbE	10–25 GbE

Cloud instance recommendations (Single-Instance / Primary-Replica)

Provider	Instance	vCPU	RAM	Notes
AWS	m7g.xlarge / c6i.2xlarge	4–8	16 GB	Production baseline (RAM is bounded by CortexAutoConfig)
AWS	m7g.2xlarge / r6i.2xlarge	8	32–64 GB	High-dimensional (3072d) or heavy concurrent query load
GCP	n2-standard-4 / n2-standard-8	4–8	16–32 GB
Azure	Standard_D4s_v5 / Standard_D8s_v5	4–8	16–32 GB

Recommended hardware — Enterprise Sharded Cluster with Raft HA

Each shard group = 1 primary + 2 replicas (3-node Raft quorum):

Component	Per shard node	Per shard group (×3)
CPU	16–32 cores	48–96 cores
RAM	32–64 GB	96–192 GB
Disk (NVMe)	500 GB–2 TB	1.5–6 TB
Network	10–25 GbE	10–25 GbE

---

Storage sizing guide

Disk usage scales with your total node and edge count (whereas peak RAM does not):

Nodes	Avg properties	Edges (×4 nodes)	768-dim vectors	BrickCoreStorage (Cortex)	HNSW index	Total Disk (est.)
100K	5 props	400K	Yes	~500 MB	~300 MB	~800 MB
1M	5 props	4M	Yes	~5 GB	~3 GB	~8 GB
10M	5 props	40M	Yes	~50 GB	~30 GB	~80 GB
100M	5 props	400M	Yes	~500 GB	~300 GB	~800 GB
1B	5 props	4B	Yes	~5 TB	~3 TB	~8 TB

With AES-256-GCM envelope encryption (KMS enabled): add ~10% overhead to the BrickCoreStorage column.

Disk scales with corpus; RAM does not

Disk usage is proportional to node/edge count as shown above. Peak RAM is not — BrickCoreStorage's brick seal-and-evict cycle and CortexAutoConfig keep peak process RSS bounded to alpha * available_ram (default 0.75) regardless of N. Never project memory usage by multiplying per-node size by N.

---

Vector backend decision guide

Backend	Memory model	Best for
hnswlib (default)	Segmented HNSW with hot/cold NVMe tiering; CortexAutoConfig bounds peak RSS via brick seal-and-evict	Production default at any scale
hnswlib + int8 quantization	~4× vector compression vs. float32	Memory-constrained hosts, large high-dim corpora
hnswlib + binary quantization	~32× vector compression vs. float32	Ultra-dense corpora where approximate recall is acceptable
rust (RustVectorIndex)	Rayon + SIMD-accelerated core	Opt-in Rust-native SIMD vector index

Set with:

P8G_VECTOR_BACKEND=hnswlib           # default
P8G_VECTOR_BACKEND=rust              # Rust-native SIMD index (opt-in)
P8G_VECTOR_QUANTIZATION=int8         # or binary — applies to hnswlib

---

Red Hat OpenShift & Container Runtime Support

Purple8 ships two production container images:

• Dockerfile.commercial: Debian/Python 3.12 slim image running as non-root appuser (UID 1000).
• Dockerfile.rhel: Certified Red Hat Universal Base Image 9 (registry.access.redhat.com/ubi9/python-312:9.5) engineered for Red Hat OpenShift's default restricted Security Context Constraint (supports arbitrary UID assignment with group 0 permissions across /data, /backups, /app/logs, /opt/venv, and /app, /licenses/LICENSE, and default non-root UID 1001).