Comparative Analysis

How does Purple8 Hyper Graph compare to every category of database and AI framework it replaces? This page is an honest, technically grounded comparison — including benchmarks, architecture trade-offs, and a frank admission of where Purple8 is not yet the best choice.

Version note

This analysis reflects Purple8 Hyper Graph v0.56.0 (June 2026) and the latest publicly available versions of all competitors at time of writing. Benchmark hardware: Apple M-series (macOS dev baseline) for Suites C–J; single m6i.2xlarge (8 vCPU, 32 GB RAM, NVMe SSD) for hybrid search tables unless noted.

What Category Is Purple8 In?

Google Gemini categorises Purple8 as a multi-model database — and that is the most accurate label available. Purple8 is not a graph database with a vector bolt-on, nor a vector store with graph annotations. It is a single embedded engine in which four data models are first-class citizens, stored in one BrickCoreStorage (Cortex) instance, queried in one Cypher statement, encrypted by one KMS envelope, and made durable by one WAL:

Data model	How it works in Purple8
Property graph	Nodes + edges + typed labels, Cypher traversal
Vector store	Dual HNSW + DiskANN, in-process, fed directly into Cypher `CALL db.vector.search`
Document store	Schemaless `properties: dict[str, Any]` on every node — arbitrary JSON depth, arrays, nested objects
Full-text / BM25	Native BM25 with stopword filtering, hybrid `text_vector_search()`

Every alternative forces you to pick one model as primary and bolt the others on. Purple8 treats them as equals.

Executive Summary

Purple8 Hyper Graph occupies a category no competitor currently owns: the Hyper Graph DB — a single embedded engine that unifies graph traversal, HNSW vector search, document storage, and BM25 full-text search with AES-256-GCM encryption at rest and a multi-tenant REST API.

Every alternative in the market today makes at least one of these trade-offs Purple8 avoids:

Trade-off	Who makes it
Graph + bolt-on vector → two query phases, JVM overhead, Docker required	Neo4j + Vector Plugin
In-memory first → no durable disk-backed storage	FalkorDB, Memgraph
Vector only → zero multi-hop reasoning, zero disambiguation	Weaviate, Pinecone, Qdrant, LanceDB
AI workflow orchestration → external state store (Redis/Postgres), no audit trail, DIY SLA	LangChain, LangGraph, CrewAI, AutoGen, Apache Airflow
AI memory → separate memory service, separate DB, no graph traversal over history	Mem0, Zep, MemGPT/Letta
Document store → separate service + sync layer + dual write risk	MongoDB Atlas, DynamoDB, Postgres JSONB

The headline benchmarks make the competitive gap concrete:

MS MARCO MRR@10 at 100k passages: Purple8 0.7511 vs BM25 baseline 0.6025 (+24.7%), at 3.53 ms p50 — 182× faster than BM25
Entity disambiguation accuracy: Purple8 1.000 vs every vector-only system 0.000, vs every hybrid dual-stack system ≤ 0.500
GraphRAG mean accuracy: Purple8 91.7% vs Neo4j+Vector / Kùzu / FalkorDB all at 79.2%
Operational footprint: 1 service, 1 pip install vs 2+ services + Docker + ETL pipelines
Journey Engine: built-in AI workflow orchestration with graph-native state, SLA enforcement, and immutable audit trails — LangGraph + Airflow compressed into a single module with no external state store required
Graph as Memory: every AI decision, human override, stage transition, and outcome is written as an immutable graph edge — queryable in Cypher, vector-searchable in-process, and feedable back as context with no separate memory service (no Mem0, Zep, or MemGPT required)
Unified Document Store: schemaless dict[str, Any] properties on every node — MongoDB, DynamoDB, and Postgres JSONB are not required; no separate service, no sync layer, no dual-write risk

No direct competitor exists at this intersection. The closest alternatives require combining two separate databases and building a synchronisation layer between them — which Purple8 eliminates entirely.

1. Market Landscape

1.1 Category Map

The database market for AI applications splits cleanly into four capability quadrants. Purple8 is the only product in Q1:

High Graph Capability
        │
   Q2   │   Q1  ← Purple8 ONLY
        │
────────┼──────── High Vector Capability
        │
   Q3   │   Q4
        │
Low Graph Capability

Quadrant	Products	Limitations
Q1 — High Graph + High Vector	Purple8 (only)	—
Q2 — High Graph + Low/No Vector	Neo4j (native), Memgraph, Amazon Neptune, Azure Cosmos Gremlin	No native HNSW; bolt-on plugins required
Q3 — Low Graph + Low Vector	Relational DBs, Elasticsearch (legacy)	Neither capability natively
Q4 — Low/No Graph + High Vector	Weaviate, Pinecone, Qdrant, LanceDB	Zero multi-hop reasoning, zero temporal chains

1.2 Competitor Roster

Competitor	Type	Deployment	Open Source	Closest to Purple8
Neo4j + Vector Plugin	Graph + bolt-on vector	Self-hosted / Managed AuraDB	Community Ed. only	Highest overlap, largest gap
Kùzu	Embedded graph	Self-hosted	✅	C++ wiring required
FalkorDB	In-memory graph+vector	Self-hosted / Cloud	✅	Durability gap
Weaviate	Vector-first	Managed / Self-hosted	✅	No graph at all
Pinecone	Managed vector	SaaS only	❌	No graph, no offline
Qdrant	Embedded/managed vector	Managed / Self-hosted / Hybrid	✅	No graph traversal
LanceDB	Embedded vector (Lance format)	Self-hosted	✅	No graph layer
Memgraph	In-memory graph	Self-hosted / Cloud	Community Ed.	No native HNSW
Amazon Neptune	Managed graph	AWS only	❌	Cloud-only, no vector
Azure Cosmos DB (Gremlin)	Managed graph	Azure only	❌	Per-RU billing, no vector
Spanner Graph	Managed distributed graph	GCP only	❌	Schema-first, no vector

2. Core Feature Matrix

Feature	Purple8	Neo4j	Kùzu	FalkorDB	Weaviate	Pinecone	Qdrant	Memgraph
Graph traversal (Cypher)	✅	✅	✅	✅	❌	❌	❌	✅
Native HNSW vector search	✅	⚠️ plugin	⚠️ manual	✅	✅	✅	✅	❌
DiskANN (disk-based ANN)	✅	❌	❌	❌	❌	❌	❌	❌
Vector + graph in one query	✅	❌ two-phase	❌	❌	❌	❌	❌	❌
Document store (schemaless)	✅	⚠️	❌	⚠️	⚠️	❌	⚠️	⚠️
BM25 full-text search	✅	✅ EE	❌	❌	✅	❌	✅	❌
AES-256-GCM encryption at rest	✅	⚠️ EE only	❌	❌	⚠️ cloud	⚠️ cloud	⚠️ cloud	❌
5 KMS providers	✅	❌	❌	❌	❌	❌	❌	❌
Multi-tenant REST API (built-in)	✅	❌	❌	❌	✅ cloud	✅ cloud	✅ cloud	❌
WAL durability (BrickCore)	✅	✅	✅	❌	✅ cloud	✅ cloud	✅ cloud	❌
Read replicas (snapshot-based)	✅	✅ EE	❌	❌	✅ cloud	✅ cloud	✅ cloud	✅ EE
Built-in RAG pipeline	✅	❌ DIY	❌	❌	❌	❌	❌	❌
LLM registry (39 models, 9 providers)	✅	❌	❌	❌	❌	❌	❌	❌
Embedding registry (21 models)	✅	❌	❌	❌	❌	❌	❌	❌
NL-to-Cypher	✅	⚠️ plugin	❌	❌	❌	❌	❌	❌
Journey Engine (AI orchestration)	✅	❌	❌	❌	❌	❌	❌	❌
SLA enforcement (built-in)	✅	❌	❌	❌	❌	❌	❌	❌
Immutable audit trail (graph edges)	✅	❌	❌	❌	❌	❌	❌	❌
Graph as Memory (AI decision history)	✅	❌	❌	❌	❌	❌	❌	❌
Human override history (queryable)	✅	❌	❌	❌	❌	❌	❌	❌
Outcome edges + learning loop	✅	❌	❌	❌	❌	❌	❌	❌
DocIntel (56+ formats)	✅	❌	❌	❌	❌	❌	❌	❌
AEC domain modules (12)	✅	❌	❌	❌	❌	❌	❌	❌
MCP server (native)	✅	❌	❌	❌	❌	❌	❌	❌
SuperGraph federation	✅ enterprise	❌	❌	❌	❌	❌	❌	❌
SOC anomaly detection & containment	✅ enterprise	❌	❌	❌	❌	❌	❌	❌
Turbo Mode (circuit breaker)	✅	❌	❌	❌	❌	❌	❌	❌
Rust performance core	✅	❌	✅	❌	❌	❌	✅	❌
`pip install` — no Docker/JVM	✅	❌	⚠️ C++	❌	❌	N/A SaaS	✅	❌
Self-hosted / air-gapped	✅	✅	✅	✅	✅	❌	✅	✅
int8/binary quantization	✅	⚠️	❌	❌	✅	✅	✅	❌

✅ = fully supported | ⚠️ = partial / plugin / external | ❌ = not supported

3. Performance

Hybrid search (vector + graph, 100K nodes)

Engine	QPS	P50	P99	Notes
Purple8 Hyper Graph (HNSW)	1,847	2.1 ms	8.7 ms	Single in-process query: vector + BFS
Purple8 Hyper Graph (DiskANN)	1,203	3.1 ms	11.2 ms	On-disk index, low memory footprint
Neo4j + vector index	892	4.8 ms	19.3 ms	Two-phase query (vector → Bolt → merge)
Kùzu + manual HNSW	741	5.9 ms	24.1 ms	Separate vector call + Cypher join
FalkorDB	634	7.2 ms	31.5 ms	Graph-only (no unified vector query)

Pure graph traversal (100K nodes, 3-hop MATCH)

Engine	QPS	P50	P99
Purple8 Hyper Graph	4,120	1.8 ms	5.9 ms
Kùzu	3,890	1.9 ms	6.4 ms
Neo4j 5.x	3,210	2.4 ms	9.1 ms

Search quality (MS MARCO MRR@10 — real sentence embeddings)

Scale	Purple8 MRR@10	BM25 MRR@10	Vector-only	Purple8 p50	BM25 p50	Speedup
2,500	0.9658	0.8233	~0.88	0.93 ms	—	—
25,000	0.8810	0.7117	~0.79	1.99 ms	—	—
100,000	0.7511	0.6025	~0.68	3.53 ms	645 ms	182×

HotpotQA multi-hop reasoning

Scale	Purple8 MRR@10	SF-F1	Purple8 p50	BM25 p50	Speedup
2,500	0.8431	0.6113	0.96 ms	—	—
25,000	0.6892	0.5186	2.17 ms	277 ms	128×
100,000	0.6489	0.5043	3.85 ms	755 ms	196×

SF-F1 (Supporting-Fact F1) measures whether Purple8 retrieves the correct reasoning paths — not just any relevant document. Purple8 SF-F1 ≥ 0.50 at all scales confirms the graph expansion is finding genuinely relevant reasoning chains.

GraphRAG task accuracy (Suite A v2, 2,500 docs)

Task	Purple8	Combined (Weaviate+Neo4j)	Neo4j-only	Weaviate-only
Multi-hop reasoning	0.500	0.500	0.500	0.500
Entity disambiguation	1.000	0.500	0.500	0.000
Knowledge synthesis (score/20)	7.5	27.7	27.7	10.3
Temporal chain	1.000	1.000	1.000	0.000
GraphRAG mean accuracy	🥇 91.7%	79.2%	79.2%	~50%

⚠️ Honest caveat on knowledge synthesis: Neo4j + combined strategies score higher on Task 3 because they fan out across all graph nodes (breadth-first, no selectivity filter). Purple8 uses targeted hybrid queries. Fan-out wins on recall but at multi-second latency — the trade-off is Purple8 <1 ms vs Neo4j multi-second scans at 100k+ docs.

Write throughput & durability (Suite C, 100k nodes)

System	Live ingest	Durability
Purple8	603 `add_node`/s · 19,024 edges/s · 37k docs/min batch	✅ WAL, hot restart 4.6 ms
Neo4j (online API)	~500–2,000 CREATE/s	✅ WAL (JVM)
Neo4j bulk import	~50k–200k nodes/min	⚠️ Offline — DB must stop
FalkorDB	Very high	❌ No WAL guarantee
Weaviate batch	~10k–50k objects/min	✅ (objects only, no edges)

Document store query (Suite D, 100k nodes)

Query	Purple8	MongoDB Atlas	PostgreSQL JSONB
Point lookup	0.073 ms p50	1–5 ms	0.5–2 ms
Nested property access (3-level)	0.004 ms p50	~0.5–2 ms	~1–5 ms
Concurrent R/W peak	251k QPS	~50k–150k QPS	~30k–100k QPS

Multi-tenancy (Suite G, 10 tenants)

Capability	Purple8	Neo4j Enterprise	Weaviate Cloud
Isolation	0 / 500 leaks	Separate DB = strong	Strong, complex ops
Aggregate throughput	507k QPS	Not published	Not published
Provisioning	8.6 ms	Seconds (new DB)	Seconds (schema)
Per-tenant DEK encryption	✅	❌	❌

Encryption overhead (Suite F)

System	Model	Overhead
Purple8	AES-256-GCM envelope, per-tenant DEK, memory-cached	+0% `add_node`; DEK cache hit 0.003 ms
Neo4j Enterprise	Filesystem encryption (LUKS/BitLocker)	~0–2% (disk-level only)
MongoDB Atlas	CSFLE / Queryable Encryption	10–30% per protected field
Weaviate	Optional at-rest disk encryption	~0% (no field-level)

MCP server latency (Suite I)

No competitor ships a native MCP server. Purple8 establishes the category benchmark.

Metric	Value
`mcp_get_node` p50	0.007 ms
`mcp_get_neighbours` p50	0.002 ms
50 concurrent sessions p95	0.022 ms

GraphRAG Mean Accuracy (v2, 2,500 docs)
─────────────────────────────────────────────────────────────
Purple8          91.7% ████████████████████████████████████████
Neo4j + Vector   79.2% ████████████████████████████████████
Kùzu + HNSW      79.2% ████████████████████████████████████
FalkorDB         79.2% ████████████████████████████████████
Weaviate-only    ~50%  ███████████████████████

Entity Disambiguation Accuracy
─────────────────────────────────────────────────────────────
Purple8          1.000 ████████████████████████████████████████
Neo4j + Vector   0.500 ████████████████████
Kùzu             0.500 ████████████████████
FalkorDB         0.500 ████████████████████
Weaviate-only    0.000 (cannot disambiguate)

Temporal Chain Accuracy
─────────────────────────────────────────────────────────────
Purple8          1.000 ████████████████████████████████████████
Graph-capable    1.000 ████████████████████████████████████████
Weaviate-only    0.000 (vector search is blind to temporal order)
Pinecone-only    0.000
Qdrant-only      0.000

4. Head-to-Head: Purple8 vs Neo4j + Vector Plugin

Neo4j is the most credible comparison point — native Cypher, enterprise maturity, 15+ years of production deployments. But its architecture fundamentally differs from Purple8.

Dimension	Purple8	Neo4j + Vector Plugin
Architecture	Single unified engine	Graph engine + bolt-on plugin
Runtime	Embedded Python (+ optional Rust Turbo core)	JVM (Java 17+)
Vector search	Native HNSW + DiskANN, in-process	Plugin call — separate HNSW index
Graph + vector in one query	✅ Single Cypher `CALL db.vector.search`	⚠️ Two-phase: vector → client merge → graph
Disk durability	✅ BrickCore WAL (fdatasync)	✅ (enterprise)
Encryption at rest	✅ AES-256-GCM envelope (5 KMS)	⚠️ Filesystem-level (EE only)
Multi-tenant REST API	✅ Built-in (FastAPI)	❌ External auth layer required
MCP server	✅ Native	❌
LLM integration	✅ 9 providers, 39 models, runtime swap	⚠️ GenAI plugin, manual config
RAG pipeline	✅ `POST /rag/query` — end-to-end	❌ DIY with LangChain
DocIntel	✅ 56+ formats	❌ Custom ETL required
Journey Engine	✅	❌
Deployment	`pip install purple8-hyper-graph`	Docker + JVM + plugin config
AEC domain modules	✅ 12	❌ Generic graph only

Where Neo4j wins

Full Cypher — 100% openCypher, APOC functions, 50+ GDS algorithms
Maturity — 15+ years of production deployments, billions of nodes proven at scale
Ecosystem — Bloom (visual), Browser, drivers for Java/JS/Python/Go/.NET, large community
Query optimizer — mature cost-based planner; Purple8 uses a fixed strategy

Where Purple8 wins

Unified hybrid query — CALL db.vector.search runs HNSW in-process and feeds directly into Cypher traversal. Neo4j requires a separate vector query phase + client-side merge = two network round-trips minimum
Latency — 2.1 ms p50 hybrid vs ~4.8 ms (separate planners + JVM overhead)
LLM depth — 9 providers, 39-model registry, runtime swap via PUT /rag/config, NL-to-Cypher, knowledge extraction. Neo4j requires assembling LangChain + vector store + retriever + prompt chain
Encryption — per-tenant DEK envelope encryption with 5 KMS providers built-in. Neo4j requires Enterprise Edition licensing for at-rest encryption
Cost — no per-core licensing

The disambiguation moat

When two graph nodes share identical embeddings (e.g., two "Alice Chen" authors), pure vector search returns both — it has no information to distinguish them. The only way to disambiguate is to traverse the graph neighbourhood. Neo4j can do this, but requires two separate query phases and client-side result merging. Purple8 does it natively in a single Cypher query because the vector index and graph adjacency list share the same in-process storage engine. Result: Purple8 1.000 vs Neo4j 0.500.

Bottom line: Neo4j for graph-first analytics, GDS algorithms, and mature ecosystem. Purple8 for AI-first workloads where hybrid query latency and LLM integration are the primary concerns.

5. Head-to-Head: Purple8 vs Kùzu

Dimension	Purple8	Kùzu
Language	Python (+ optional Rust core)	C++ (Python bindings)
Install	`pip install purple8-hyper-graph`	`pip install kuzu` (+ C++ toolchain)
Vector search	✅ Native HNSW + DiskANN	⚠️ Manual hnswlib wiring, separate index
Graph + vector in one query	✅	❌ Application code must merge
Document store	✅	❌
BM25 full-text	✅	❌
Encryption at rest	✅ AES-256-GCM (5 KMS)	❌
Multi-tenancy	✅ JWT RBAC per tenant	❌ Single-tenant
MCP server	✅	❌
LLM / RAG integration	✅ 9 providers, RAG pipeline	❌ Pure database
REST API	✅ FastAPI (built-in)	❌ Custom server required
GraphRAG mean accuracy	91.7%	79.2%
Disambiguation accuracy	1.000	0.500
AEC modules	✅ 12	❌

Kùzu is an excellent embedded graph engine and a legitimate choice for open-source analytical workloads. But it treats HNSW as a separate module — there is no unified query interface, no encryption, no multi-tenancy, and no document store. It is a graph engine; Purple8 is a knowledge platform.

Bottom line: Kùzu for open-source embedded graph analytics. Purple8 when hybrid vector+graph is a first-class concern and enterprise security matters.

6. Head-to-Head: Purple8 vs FalkorDB

Dimension	Purple8	FalkorDB
Storage model	✅ Disk-backed (BrickCore/Cortex)	⚠️ In-memory first (Redis-based)
Durability on restart	✅ WAL fdatasync	⚠️ RDB/AOF snapshots only
Vector search	✅ Native HNSW + DiskANN	✅ In-memory HNSW
Encryption at rest	✅ AES-256-GCM (5 KMS)	❌
Deployment	`pip install`	Docker + Redis
Multi-tenant REST API	✅	❌
GraphRAG mean accuracy	91.7%	79.2%
Disambiguation accuracy	1.000	0.500

FalkorDB's Redis foundation means that an unplanned restart loses all non-persisted data. For production knowledge graphs — especially in regulated industries — this is a disqualifying constraint. Purple8's WAL guarantees that every write that returns 200 OK is durable.

Bottom line: FalkorDB for open-source in-memory Cypher stores where the graph fits in RAM and durability is not a requirement. Purple8 for disk-backed durability at scale, enterprise security, and AI-first use cases.

7. Head-to-Head: Purple8 vs Vector-Only DBs (Weaviate / Pinecone / Qdrant / LanceDB)

A vector database answers one question: "What is semantically similar to this query?" It cannot answer:

"Who wrote this paper, given two authors with the same name?" (disambiguation requires graph context)
"What happened first in this timeline?" (temporal chains are a pure graph problem)
"How are these two documents related through shared citations?" (multi-hop traversal)

These are the exact queries that define RAG quality in production.

Accuracy comparison

Task	Purple8	Weaviate	Pinecone	Qdrant
Entity disambiguation	✅ 1.000	❌ 0.000	❌ 0.000	❌ 0.000
Temporal chain	✅ 1.000	❌ 0.000	❌ 0.000	❌ 0.000
Multi-hop reasoning	✅ 0.500	0.500*	0.500*	0.500*
GraphRAG mean accuracy	🥇 91.7%	~50%	~50%	~50%

*Multi-hop appears equal at small scale; diverges at 100k+ nodes where graph traversal is the only tractable approach.

Operational comparison

Dimension	Purple8	Weaviate Cloud	Pinecone	Qdrant Cloud
Self-hosted	✅ `pip install`	✅ Docker	❌ SaaS only	✅ Docker
Offline / air-gapped	✅	⚠️ self-hosted only	❌	✅ self-hosted
Graph traversal	✅ Native Cypher	❌	❌	❌
Encryption at rest (built-in)	✅ AES-256-GCM	⚠️ Cloud-managed	⚠️ Cloud-managed	⚠️ Cloud-managed
MCP server	✅ Native	❌	❌	❌
Document store + full-text	✅ Built-in	⚠️ Properties only	❌	⚠️ Payload only
AEC domain modules	✅ 12	❌	❌	❌
Starting price	Free (self-hosted)	$45/mo	$50/mo min	Free tier → usage-based
Data residency control	✅ Full	Limited	❌ US AWS only (free)	✅ self-hosted

LanceDB note: LanceDB is an excellent choice for analytical / ML feature store workloads (Apache Lance columnar format + DuckDB integration). However: no graph traversal, no Cypher, no encryption at rest, no multi-tenant REST API, no document store with relationship edges. It is not a substitute for knowledge graph workloads.

Bottom line: Weaviate, Pinecone, Qdrant for pure ANN similarity search with no graph requirements. Purple8 for any workload requiring disambiguation, temporal reasoning, or multi-hop traversal.

8. Head-to-Head: Purple8 vs Graph-Only DBs (Memgraph / Neptune / Cosmos Gremlin)

Dimension	Purple8	Memgraph	Amazon Neptune	Azure Cosmos Gremlin
Storage model	Disk-backed (BrickCore/Cortex)	In-memory	Managed (AWS)	Managed (Azure)
Native HNSW vector search	✅	❌	❌	❌
Deployment	`pip install`	Docker	AWS console	Azure portal
Cloud dependency	None	None	Required (AWS)	Required (Azure)
Query language	openCypher + GraphQL	openCypher	Gremlin / Cypher / SPARQL	Gremlin
Encryption at rest	✅ AES-256-GCM	⚠️ OS-level	✅ (managed)	✅ (managed)
Cost model	Free (self-hosted)	Free (OSS)	Per-request RU billing	Per-RU billing
Vector + graph unified query	✅	❌ needs ext. vector DB	❌	❌
LLM integration	✅	❌	❌	❌
Journey Engine	✅	❌	❌	❌

Memgraph is a strong in-memory graph competitor with Kafka/Pulsar streaming. The gap: no native HNSW, so RAG pipelines must add a separate vector DB — landing back in the dual-stack problem. Memgraph also must fit the entire graph in RAM.

Neptune and Cosmos Gremlin are managed cloud services with per-request billing, mandatory cloud dependency, and no native vector capability. For air-gapped deployments common in AEC, defence, and healthcare, they are architecturally ineligible.

9. Head-to-Head: Purple8 vs Spanner Graph

Dimension	Purple8	Spanner Graph
DDL prerequisite	None — write data immediately	`CREATE PROPERTY GRAPH` DDL required before first write
Schema model	Data-first, emergent	Schema-first
Vector search	✅ HNSW + DiskANN	❌ No native vector index
Self-hosted / multi-cloud	✅	❌ GCP only
Cost	Free (self-hosted)	$15k–$80k/year

Spanner Graph is the right choice for globally-distributed transactional graphs on GCP with stable, known schemas. Purple8 is the right choice for AI discovery workloads where the schema is emergent — entities and relationships are extracted by LLMs and the structure is discovered, not predefined.

python

# Purple8: no schema required, build from LLM extraction
for doc in documents:
    nodes, edges = extractor.extract(doc.text)
    engine.batch_add_nodes(nodes)
    engine.batch_add_edges(edges)

# Infer the schema from what was actually discovered
schema = create_schema_from_graph(engine)

Schema-first systems cannot support this pattern. Purple8 was designed for it.

10. Head-to-Head: Purple8 Journey vs AI Orchestration Frameworks

Journey is Purple8's built-in AI workflow orchestration engine. It is not a database feature bolted on — it is a complete orchestration layer that combines:

LangGraph's idea of stateful, graph-structured agent workflows
Airflow's idea of stage-based DAG execution with scheduling and SLA policies

But it does this without any external dependencies, storing all state directly in the graph — making every transition, every AI decision, and every SLA breach instantly queryable with Cypher.

Architecture comparison

Dimension	LangGraph	Apache Airflow	Purple8 Journey
Primary purpose	LLM agent state machines	Data pipeline DAG scheduling	AI workflow orchestration over real-world entities
State storage	External (Redis, Postgres, in-memory)	Postgres metadata DB	Graph-native — every transition is an `ADVANCED_TO` edge
AI decision integration	LLM nodes in graph	Operators + hooks (DIY)	Built-in `JourneyAIAdvisor` — fires on stage entry, SLA warn, or manually
Audit trail	DIY (LangSmith optional)	Task instance logs	Immutable `AI_ADVISED` graph edges — append-only, queryable in Cypher
SLA enforcement	❌ Not a concept	✅ `sla_miss_callback` (task-level)	✅ `SLAPolicy(warn_after_seconds, breach_after_seconds)` per stage with background monitor
Human-in-the-loop	✅ `interrupt` node	⚠️ Manual sensors	✅ `auto_execute=False` — LLM recommends, human confirms
Real-time events	❌	❌	✅ CDC `EventBus` — WebSocket push on every advance/breach
Graph retrieval at decision time	Separate tool call (vector DB + graph DB)	N/A	✅ Same engine — zero latency, no network hop
Multi-tenant isolation	DIY	Workspace/role RBAC	✅ Per-tenant `JourneyEngine` with JWT RBAC
Install	`pip install langgraph` + state store	`pip install apache-airflow` + Postgres + Celery	`pip install purple8-hyper-graph` — the state store is the graph you already have
Query past state	Through state store (Redis/Postgres queries)	Airflow metadata DB (SQL)	Cypher — full graph traversal over all instances and transitions

What Journey does that LangGraph cannot

LangGraph is designed for single-session agent flows — a chain of LLM calls with branching logic within one conversation. Journey is designed for long-running multi-system entity tracking:

LangGraph mental model:
  User message → agent loop → tool calls → response
  Duration: milliseconds to minutes
  State: in-memory or Redis (ephemeral)

Journey mental model:
  Entity (customer, document, case) → defined stage sequence → multiple actors/systems
  Duration: hours to weeks
  State: durable graph edges (append-only, crash-safe, queryable forever)

A LangGraph workflow that loses its Redis state store loses all in-flight agent sessions. A Journey instance that survives a crash restarts exactly where it left off — the graph edges are the state, and WAL fdatasync ensures they survive.

What Journey does that Airflow cannot

Airflow orchestrates data pipelines — tasks that run on a schedule and process data. Journey orchestrates entity lifecycles — a real-world object (a person, a document, a financial transaction) moving through a business process.

Airflow strength	Journey strength
`BashOperator`, `PythonOperator`, complex DAG dependencies	Per-entity stage tracking — each entity has its own running instance
Cron scheduling, backfill, retry	SLA on a per-instance basis — each entity can have different SLA urgency
Thousands of tasks in one DAG	Thousands of concurrent instances of the same journey type
Task logs in Airflow metadata DB	Audit trail as graph edges — queryable with Cypher, traversable with hybrid search
No concept of AI decision-making	Built-in `JourneyAIAdvisor` — LLM advises on every stage with full context
No concept of the entity	Entity is the primary object — `je.start("loan_application", entity_id="customer_123")`

For data engineering and ETL scheduling, Airflow remains the right tool. For AI-driven entity lifecycle management, Journey is a fundamentally better architecture.

What Journey does that CrewAI / AutoGen cannot

CrewAI and AutoGen are multi-agent conversation frameworks — LLMs talking to each other to complete a task. They have no concept of:

A stage sequence with owner systems
SLA enforcement with background monitoring
Durable state that survives process restarts
An immutable audit trail of decisions
Multi-tenant isolation per journey type

Journey's JourneyAIAdvisor can be thought of as a single "agent" in the CrewAI sense — but it operates with far more context (full audit history + SLA health + workflow definition) and all its decisions are written to an append-only graph that can be queried, traversed, and vector-searched indefinitely.

Journey capability summary

Feature	Journey
`JourneyDefinition` — repeatable process template	✅ Stored as graph node
`JourneyInstance` — per-entity running instance	✅ Stored as graph node
`StageSpec` — named stage with owner + SLA + AI config	✅
`SLAPolicy(warn_after_seconds, breach_after_seconds)`	✅ Background `SLAMonitor` thread
`SLA_BREACHED` / `SLA_WARNED` edges	✅ Append-only, queryable
`ADVANCED_TO` transition edges	✅ Immutable audit trail
`JourneyAIAdvisor` — LLM decision on every trigger	✅ `ON_ENTER`, `ON_SLA_WARN`, `ON_SLA_BREACH`, `MANUAL`
`AIStepConfig.auto_execute` — human-in-the-loop toggle	✅
AI actions: `suggest_advance`, `force_advance`, `cancel`, `flag`, `hold`, `annotate`, `no_action`	✅ All written as `AI_ADVISED` edges
`EventBus` CDC — WebSocket push on every transition	✅
Cypher queries over all journey state	✅ `MATCH (i:JourneyInstance)-[t:ADVANCED_TO]->()`
Hybrid vector search over journey metadata	✅ Same engine, zero latency
Multi-tenant per `tenant_id`	✅
Rust-accelerated SLA scanning (`JourneyEngineCore`)	✅ Optional Turbo core
REST API (`/journey/*` endpoints)	✅ Built into `build_journey_router()`
Webhook receiver integration	✅ `WebhookReceiver` connector

"Don't plug Purple8 into your agent framework. Journey IS your agent framework — with graph memory, hybrid search, audit trails, human-in-the-loop oversight, and SLA enforcement built in."

11. Graph as Memory — AI That Learns From Its Own History

What this is

Most AI systems treat memory as an external concern — Redis for short-term context, a vector store for long-term retrieval, a separate analytics database for outcomes. Purple8 eliminates all three by making the graph itself the memory layer.

There is no MemoryLayer class to instantiate and no background training process. Every AI decision, every human override, and every stage transition is written to the graph as an immutable edge. The graph is the memory. You query it with Cypher, the same way you query everything else.

What gets written automatically

AI_ADVISED edges — every time JourneyAIAdvisor.advise() runs:

(JourneyInstance) -[:AI_ADVISED]-> (Stage)

Properties: action_type, recommended, reasoning, confidence, model, timestamp

Nothing is overwritten. Ten runs on the same instance produce ten AI_ADVISED edges — a complete history of what the AI said and why, queryable forever.

ADVANCED_TO edges — every human or automated stage transition:

(JourneyInstance) -[:ADVANCED_TO]-> (Stage)

Properties: actor, from_stage, to_stage, notes, timestamp

HITLTask nodes — when the AI escalates to a human reviewer, a HITLTask node records the assignee, decision, rationale, and resolution time.

SLA_BREACHED edges — appended when a stage exceeds its SLA. Never deleted, never modified.

Querying the memory (standard Cypher)

cypher

-- What did the AI recommend, in order?
MATCH (ji:JourneyInstance {id: "ji:9871-abc"})-[r:AI_ADVISED]->(s:Stage)
RETURN r.timestamp, r.action_type, r.recommended, r.reasoning, r.confidence
ORDER BY r.timestamp ASC

-- Where did humans override the AI?
MATCH (ji:JourneyInstance)-[:AI_ADVISED]->(s:Stage)
MATCH (ji)-[:HITL_TASK]->(t:HITLTask {decision: "reject"})
RETURN ji.id, s.name AS ai_recommended, t.rationale, t.assignee
LIMIT 50

-- Override rate by journey type (run monthly — high rate = AI reasoning mismatch)
MATCH (ji:JourneyInstance)-[:AI_ADVISED]->(s)
OPTIONAL MATCH (ji)-[:HITL_TASK]->(t:HITLTask {decision: "reject"})
WITH ji.journey_type AS jtype, count(s) AS ai_calls, count(t) AS overrides
RETURN jtype, ai_calls, overrides,
       round(100.0 * overrides / ai_calls, 1) AS override_pct
ORDER BY override_pct DESC

-- What AI actions precede SLA breaches?
MATCH (ji:JourneyInstance)-[:SLA_BREACHED]->(s:Stage)
MATCH (ji)-[ai:AI_ADVISED]->(prev)
WHERE ai.timestamp < s.breached_at
RETURN ai.action_type, ai.reasoning, count(*) AS frequency
ORDER BY frequency DESC LIMIT 10

The learning loop (no retraining required)

Write an OUTCOME edge when a journey closes, then query patterns from closed instances and pass them as few_shot_patterns to the next advise() call:

python

# 1. Write the outcome
engine.add_edge(
    src_id="ji:9871-abc", dst_id="ji:9871-abc",
    edge_type="OUTCOME",
    properties={"result": "won", "closed_at": "2026-03-25T16:00:00Z",
                "revenue": 2_000_000, "cycle_days": 47},
)

# 2. Query patterns from closed-won deals
patterns = engine.query("""
    MATCH (ji:JourneyInstance {journey_type: $jtype})-[o:OUTCOME {result: "won"}]->()
    MATCH (ji)-[ai:AI_ADVISED]->(s)
    RETURN ai.action_type, ai.recommended, avg(o.cycle_days) AS avg_cycle
    ORDER BY avg_cycle ASC LIMIT 5
""", {"jtype": "sales-cycle"})

# 3. Inject patterns into the next decision as context
recommendation = await advisor.advise(
    instance=current_instance,
    audit_history=history,
    few_shot_patterns=patterns,   # closed-won patterns → system prompt
)

No retraining. No embedding rebuild. No external memory service. The graph stores the signal; you decide which signal to surface as context.

Real-time memory via CDC

EventBus fires on every graph write — including AI_ADVISED edges — so downstream systems react the moment a decision lands:

python

async with bus.subscribe(tenant_id="acme") as queue:
    event = await queue.get()
    if event.event_type == EventType.EDGE_ADDED:
        if event.properties.get("edge_type") == "AI_ADVISED":
            await post_to_slack(event.properties)

Or stream over WebSocket with no Python process required:

ws://localhost:8100/ws/changes?tenant_id=acme&event_type=edge_added

Competitor comparison — AI memory

Capability	Purple8	LangGraph	LangChain / LangSmith	Mem0	Zep	MemGPT / Letta
AI decision history (immutable edges)	✅ Native graph edges	❌ External store	⚠️ LangSmith traces (separate SaaS)	❌	❌	❌
Human override history	✅ `HITLTask` nodes, queryable in Cypher	⚠️ `interrupt` node, state store only	❌	❌	❌	❌
SLA breach history	✅ `SLA_BREACHED` edges, append-only	❌ Not a concept	❌	❌	❌	❌
Outcome edges (win/loss/result)	✅ Self-edge on instance node	❌	❌	❌	❌	❌
Query memory with Cypher	✅ Same engine	❌ Redis/Postgres queries	❌	❌	❌	❌
Vector search over memory	✅ In-process HNSW, zero latency	❌ Separate vector DB required	❌	✅ (separate)	✅ (separate)	✅ (separate)
Memory + graph traversal in one query	✅	❌	❌	❌	❌	❌
Few-shot pattern injection	✅ `few_shot_patterns` argument	❌ DIY	❌ DIY	❌	❌	⚠️ Persona context only
Real-time CDC on memory writes	✅ `EventBus` / WebSocket	❌	❌	❌	❌	❌
Multi-tenant memory isolation	✅ Per-tenant `JourneyEngine` + JWT RBAC	❌ DIY	❌	⚠️	❌	❌
No separate memory service	✅ Graph is the memory	❌ Redis/Postgres required	❌ LangSmith is separate	❌ Separate service	❌ Separate service	❌ Separate service
Encryption at rest (memory data)	✅ AES-256-GCM, 5 KMS	❌ Delegated to Redis/Postgres	❌ SaaS	❌	❌	❌
Self-hosted / air-gapped	✅	⚠️	❌ LangSmith is SaaS	⚠️ OSS + managed	⚠️ OSS + managed	⚠️ OSS

Mem0, Zep, MemGPT/Letta are standalone AI memory services (separate pip install, separate database, separate API). They provide semantic memory for LLM conversations. Purple8's memory is structurally different: it is the operational history of real-world entity lifecycles — every stage transition, every AI recommendation, every human override — stored as durable graph edges in the same engine that runs your queries.

What this is not

To be explicit: Purple8 does not have a background process that automatically re-ranks or updates embeddings based on feedback. The AI advisor does not update its own weights — it is a stateless LLM call that receives whatever context you pass it. The pattern described here (write outcomes → query patterns → pass patterns as context) is simple on purpose. The graph handles persistence and traversal; you decide which signal is worth surfacing.

12. Unique Differentiators (Eight Moats)

These capabilities exist in Purple8 v0.56.0 and are not matched by any single competitor.

Moat 1 — Entity Disambiguation (1.000 vs ≤ 0.500)

No competitor achieves perfect disambiguation. When two graph nodes share identical embeddings, pure vector search returns both with no way to choose. The only tractable solution is to traverse the graph neighbourhood atomically with the vector search. No dual-stack architecture can provide this without client-side merging — which introduces race conditions. Purple8 does it in a single in-process Cypher statement.

Moat 2 — Zero-Drift Architecture

Dual-stack systems have inherent graph-vector data drift because they write to two separate stores:

Dual-stack write (Weaviate + Neo4j):
  1. Write node to Neo4j → success
  2. Upsert embedding to Weaviate → network timeout
  3. Result: graph has the node; vector index does not
  4. Next query: graph traversal finds it; vector search misses it
  → Silent data drift, no error surfaced

Purple8 write:
  1. Write node + embedding in single atomic operation to the WAL
  2. Result: both consistent or both rolled back
  → Impossible to have drift between graph and vector state

At scale this is not just a latency advantage — it is a data integrity guarantee.

Moat 3 — AES-256-GCM Envelope Encryption (Built-in, 5 KMS)

No competitor provides built-in at-rest encryption for a self-hosted graph+vector store:

Neo4j requires Enterprise Edition licensing for filesystem-level encryption
Weaviate, Qdrant, Pinecone delegate to cloud provider encryption
Purple8 provides cryptographic envelope encryption per-tenant DEK, per-field granularity, with zero-downtime key rotation across 5 KMS providers (Local, HashiCorp Vault, AWS KMS, GCP KMS, Azure Key Vault)

This is critical for HIPAA, ISO 27001, and AEC regulated contracts.

Moat 4 — Single `pip install` + Embedded Runtime

Purple8 is the only graph+vector system that installs in one command with no JVM, no Docker, no C++ build toolchain. This eliminates an entire class of deployment and reproducibility problems, and makes Purple8 the only viable option for edge, air-gapped, and developer-local deployments.

Moat 5 — AEC Vertical + DocIntel (56+ Formats)

Purple8 ships 12 AEC industry modules (IFC, BIM, DXF, SAP IDoc, P6 schedule, etc.) and DocIntel with 56+ format parsers. No general-purpose database vendor addresses this market. This is currently a category-of-one: the only knowledge graph purpose-built for construction, engineering, and asset management workflows.

Moat 6 — Journey Engine (Graph-Native AI Workflow Orchestration)

No database vendor — graph or vector — ships a built-in AI workflow orchestration engine. LangGraph requires an external state store. Airflow requires Postgres + Celery workers and has no concept of AI decision-making. CrewAI/AutoGen are stateless conversation frameworks with no SLA enforcement, no durable audit trail, and no entity-lifecycle model.

Journey eliminates the need for any of these systems for entity-lifecycle workflows. Every stage transition is a durable graph edge. Every AI decision is an immutable AI_ADVISED edge queryable in Cypher. SLA monitoring runs as a background thread in the same process, with no additional infrastructure. Category-of-one: no competitor — graph DB, vector DB, or agent framework — offers this combination.

Moat 7 — Unified Document Store

Every Purple8 node carries a schemaless properties: dict[str, Any] — arbitrary JSON depth, arrays, nested objects — stored in the same BrickCoreStorage (Cortex) instance as the graph, encrypted by the same KMS envelope, made durable by the same WAL. Teams building AI applications no longer need a separate document database:

MongoDB Atlas ($57+/mo) — eliminated
DynamoDB (on-demand billing, AWS-only) — eliminated
Postgres JSONB (separate service, separate schema, separate backup) — eliminated

One atomic write covers all four capabilities: document, graph, vector, full-text. No dual-write path. No ETL sync job. No race condition between the document record and the graph node.

Moat 8 — Graph as Memory (No External Memory Service)

Mem0, Zep, and MemGPT/Letta are standalone AI memory services — separate install, separate database, separate API. They store conversation context for LLM sessions.

Purple8's memory is architecturally different: it is the operational history of real-world entity lifecycles. Every AI_ADVISED edge, every ADVANCED_TO transition, every HITLTask node, every SLA_BREACHED edge, and every OUTCOME edge is a durable, encrypted, Raft-replicated graph edge in the same engine that runs your queries. You query it with Cypher. You vector-search it in-process. You feed patterns from it back to the AI as context — with no separate service, no additional pip install, and no data leaving the graph.

No competitor — graph DB, vector DB, orchestration framework, or AI memory service — offers this combination. See Section 11 for the full breakdown.

13. RAG Studio — Built-In Pipeline with Model Registry & Evaluation

Purple8 ships a complete RAG pipeline accessible via REST API, MCP tool, Python SDK, and frontend UI. No LangChain, no glue code, no separate vector database.

Question → Embed → [RouterAgent] → Vector / BM25 / Graph-BFS / Hybrid → [RRF Fusion] → (Rerank) → Context Assembly → LLM → Grounded Answer

v0.31.0 adds Multi-Index Routing, Late Chunking, and RRF Fusion. v0.32.0 adds Agentic Chunking Intelligence (ChunkingAgent) and per-label query re-embedding — see §14.

LLM model registry — 39 models, 9 providers:

Provider	Models
OpenAI	gpt-5.4, gpt-5.4-mini, gpt-5.4-nano, o3, o4-mini
Anthropic	claude-sonnet-4, claude-opus-4, claude-3.5-haiku
Google	gemini-3.1-pro-preview, gemini-3-flash, gemini-2.5-flash, gemini-2.5-pro
Vertex AI	gemini-2.5-flash, gemini-2.5-pro (VPC-SC / CMEK)
Mistral	mistral-large, mistral-medium, magistral-medium, codestral
Cohere	command-a, command-a-reasoning, command-r7b
AWS Bedrock	nova-pro, nova-lite, nova-micro, claude-sonnet-4
Azure OpenAI	gpt-5.4, gpt-5.4-mini (managed identity, VNET)
Self-hosted	llama-3.3-70b, llama-3.1-8b, mistral-nemo-12b, qwen3-next-80b, deepseek-r1

Switch providers and models at runtime via PUT /rag/config — no code changes, no redeployment.

Per-tenant configuration — 23 parameters across 5 categories (v0.31.0):

Category	Parameters
Chunking	`chunking_strategy` (fixed, recursive, semantic, sentence_window, parent_child, markdown_header, late, syntactic), `chunk_size`, `chunk_overlap`, `chunk_overlap_percent`, `late_chunking_model`, `late_chunking_max_tokens`, `chunking_agent_enabled`
Retrieval	`retrieval_k`, `embedding_model`, `min_similarity`, `hybrid_weight`, `mmr_diversity`, `reranker`, `fusion_strategy` (weighted \| rrf), `rrf_k`, `routing_enabled`
Generation	`provider`, `model`, `temperature`, `max_tokens`, `top_p`, `system_prompt`
Evaluation	`evaluation_enabled` (Prometheus export of quality scores)

🔀 Multi-Index Router — `RouterAgent` (v0.31.0)

The RouterAgent dispatches each query to the optimal retrieval strategy based on node label and query confidence — configured in a per-tenant rag_routing.json file.

bash

# Enable routing
curl -X PUT /rag/config \
  -d '{"routing_enabled": true}'

# Configure per-label routing rules
curl -X PUT /rag/routing \
  -d '{
    "Document": [{"strategy": "hybrid",  "min_confidence": 0.0}],
    "Person":   [{"strategy": "graph",   "min_confidence": 0.8, "expand_hops": 2},
                 {"strategy": "vector",  "min_confidence": 0.0}],
    "Code":     [{"strategy": "bm25",   "min_confidence": 0.0}],
    "*":        [{"strategy": "hybrid",  "min_confidence": 0.0}]
  }'

# Query — router picks the best strategy per label automatically
curl -X POST /rag/query \
  -d '{"question": "Who owns module auth?", "labels": ["Code"]}'

Each response now includes a "retrieval" metadata field:

json

{
  "answer": "...",
  "retrieval": {
    "strategy": "bm25",
    "label_matched": "Code",
    "latency_ms": 1.4,
    "fusion": null
  }
}

📄 Late Chunking — `chunking_strategy: "late"` (v0.31.0)

Late Chunking embeds the entire document with a long-context model first, then pools the resulting token embeddings into context-aware chunk vectors. Cross-sentence semantic signal is preserved — unlike fixed or recursive chunking which embeds isolated chunks.

bash

curl -X PUT /rag/config \
  -d '{
    "chunking_strategy": "late",
    "late_chunking_model": "voyage-4-large",
    "late_chunking_max_tokens": 28000
  }'

Model	Context	Provider
`voyage-4-large`	32 K tokens	Voyage AI (recommended)
`jina-embeddings-v3`	8 K tokens	Jina AI
`text-embedding-3-large`	8 K tokens	OpenAI (fallback)

🔗 RRF Fusion — `fusion_strategy: "rrf"` (v0.31.0)

Reciprocal Rank Fusion (RRF) replaces the old weighted-sum hybrid as the fusion strategy. RRF is rank-position–based so it handles mismatched score distributions (BM25 vs cosine similarity vs graph-hop count) without manual weight tuning.

bash

curl -X PUT /rag/config \
  -d '{"fusion_strategy": "rrf", "rrf_k": 60}'

RRF score formula: score(d) = Σ 1 / (k + rank_r(d)) across all retrievers. k=60 is the empirically optimal constant from the TREC literature (Cormack et al. 2009).

Built-in evaluation — 5 DeepEval metrics:

bash

curl -X POST /rag/evaluate \
  -H "Authorization: Bearer $TOKEN" \
  -d '{"test_cases": [{"question": "...", "expected_answer": "..."}],
       "metrics": ["faithfulness", "answer_relevancy", "contextual_precision",
                   "contextual_recall", "hallucination"]}'

Capability	Neo4j	Kùzu	FalkorDB	Purple8
Built-in RAG pipeline	❌ DIY	❌ DIY	❌ DIY	✅ `POST /rag/query`
LLM model registry	❌ Manual	❌ N/A	❌ N/A	✅ 39 models, 9 providers
Runtime model swap	❌ Redeploy	❌ N/A	❌ N/A	✅ Config change, no restart
Chunking strategies	❌ DIY	❌ DIY	❌ DIY	✅ 8 strategies (incl. late, syntactic) + `ChunkingAgent` auto-selection
Per-tenant RAG config	❌ DIY	❌ N/A	❌ DIY	✅ `PUT /rag/config` (23 params)
Multi-index routing	❌ DIY	❌ DIY	❌ DIY	✅ `RouterAgent` — per-label strategy dispatch
RRF / fusion strategy	❌ DIY	❌ DIY	❌ DIY	✅ `fusion_strategy: weighted \| rrf`
Quality evaluation	❌ DIY	❌ DIY	❌ DIY	✅ `POST /rag/evaluate` (5 metrics)

14. Agentic Chunking Intelligence & Multi-Model Index (v0.32.0)

The Problem: Single-Model Vector Spaces Degrade on Mixed Corpora

When legal contracts, Python source files, and clinical notes all share one embedding model, retrieval degrades. A model tuned for natural language prose assigns nonsensical distances to code tokens. A code-optimised model loses legal nuance. The result: a single flat vector space where nearest-neighbours are wrong by construction for at least two of the three doc types.

Purple8 v0.32.0 solves this by routing each document into a dedicated sub-space at ingest time, then re-embedding queries into that same sub-space at search time.

Architecture: `ChunkingAgent` + `RouterAgent` Close the Loop

Ingest path
───────────
DocIntel job_to_preview()
        │
        ▼ DocIntelChunkingHint (zero re-classification)
ChunkingAgent.classify(text, filename, mime_type, docintel_hint?)
        │
        ▼ ChunkingDecision {doc_type, chunking_strategy, embedding_model, …}
/ingest/commit  →  node properties store classification metadata
        │
        ▼
HNSW index (per-label, per-model sub-space)

Query path
──────────
RouterAgent.route(query, embedding, labels)
        │
        ├─ RoutingRule has embedding_model?
        │       │ yes → _reembed_query(query, rule.embedding_model)
        │       │         ↳ Voyage / Jina / OpenAI — never raises
        │       │ no  → use default embedding
        │
        ▼  active_embedding (label-matched model)
_dispatch()  →  Vector / BM25 / Hybrid / Graph-BFS

The key insight: DocIntel already knows the doc type from its extraction pipeline. DocIntelChunkingHint is the wire that passes that knowledge directly into ChunkingAgent.classify(), bypassing heuristic re-classification entirely — confidence 1.0, zero latency cost.

Default Domain → Model Mapping

Doc Type	Chunking Strategy	Embedding Model	Why
`legal_contract`	late	`voyage-4-large`	Long-context cross-sentence semantic signal; preserves clause references
`research_paper`	late	`voyage-4-large`	Abstract ↔ methodology ↔ results cross-reference; 32 K context
`code`	syntactic	`voyage-code-3`	Code-tuned tokenisation; syntactic chunking preserves function/class boundaries
`financial_report`	semantic	`voyage-finance-2`	Domain vocabulary (EBITDA, CAGR); semantic boundary detection for tables/narratives
`clinical_note`	sentence_window	`voyage-3`	Short factual sentences; sliding window preserves diagnostic context
`transcript`	sentence_window	`voyage-3`	Turn-by-turn sentences; window captures speaker transitions
`document`	semantic	`voyage-4-large`	General-purpose; semantic chunking for natural paragraph breaks
`markdown`	markdown_header	`text-embedding-3-small`	Header-aware splits; lightweight model sufficient for structured docs
`*` (catch-all)	fixed	`text-embedding-3-small`	Safe default for unknown types

DocIntel Fast-Path vs Heuristic Classification

ChunkingAgent.classify() runs two code paths depending on whether a DocIntelChunkingHint is provided:

Path	Trigger	Confidence	How
DocIntel fast-path	`docintel_hint` present with `doc_type`	1.0 (or hint's value)	Registry lookup on `hint.doc_type`; falls back to hint's `chunking_hint` + `suggested_embedding_model` if no specific rule
Heuristic	No hint	0.40–0.95	File extension → MIME type → content pattern scoring; fallback `"document"` at 0.40

Heuristic confidence signals:

File extension (.py, .js, .tsx → code at 0.95; .md, .rst → markdown at 0.95)
MIME type (text/x-python → code at 0.90)
Content patterns: legal keywords, code structure markers, clinical vocabulary, financial terms, research paper signals — scored 0.50–0.90

Per-Label Query Re-Embedding

When RouterAgent matches a RoutingRule that specifies an embedding_model different from the tenant default, it re-embeds the query before dispatching to the vector index:

python

# rag_routing.json
{
  "Code": [{"strategy": "hybrid", "embedding_model": "voyage-code-3", "min_confidence": 0.0}],
  "Document": [{"strategy": "vector", "embedding_model": "voyage-4-large", "min_confidence": 0.0}]
}

bash

# Enable routing + chunking agent
curl -X PUT /rag/config \
  -d '{"routing_enabled": true, "chunking_agent_enabled": true}'

# Ingest — classification metadata auto-attached to every node
curl -X POST /ingest/commit \
  -d '{
    "source_name": "contracts_q1.pdf",
    "doc_type": "legal_contract",
    "chunking_hint": "late",
    "suggested_embedding_model": "voyage-4-large",
    "entities": [...]
  }'

# Query — RouterAgent re-embeds with voyage-code-3 when label=Code
curl -X POST /rag/query \
  -d '{"question": "How does auth middleware work?", "labels": ["Code"]}'

Response includes re-embedding metadata:

json

{
  "answer": "...",
  "retrieval": {
    "strategy": "hybrid",
    "label_matched": "Code",
    "embedding_model_used": "voyage-code-3",
    "latency_ms": 3.2
  }
}

Competitive Differentiator

Capability	Neo4j	Weaviate	LanceDB	Purple8
Per-doc-type embedding model	❌ Manual config	⚠️ Per-class, static	❌ Manual	✅ Auto-classified at ingest
Per-query re-embedding	❌ DIY	❌ DIY	❌ DIY	✅ `_reembed_query()` in `RouterAgent`
DocIntel zero-reclassification fast-path	❌ N/A	❌ N/A	❌ N/A	✅ `DocIntelChunkingHint`
Classification stored on nodes	❌ DIY	❌ DIY	❌ DIY	✅ `chunking_props` merged at `/ingest/commit`
Runtime model swap without re-ingest	❌ DIY	❌ Class recreation	❌ DIY	✅ `PUT /rag/config`

15. SOC Agent — Built-in Security Operations (v0.33.0)

No competitor in the graph or vector database space ships an active, self-calibrating security layer as part of the database engine. Purple8 does.

The Problem No Competitor Solves

Production graph databases hold sensitive data: PII, financial records, AI-generated knowledge graphs, tenant-private embeddings. They are also exposed to:

Credential stuffing — brute-force auth bursts against the API
Data exfiltration — large result sets or bulk exports that drain knowledge graphs
RAG poisoning — high-volume ingest designed to corrupt vector baselines
Destructive Cypher — DETACH DELETE, DROP, or TRUNCATE injected via compromised applications
Embedding inversion — high-frequency vector queries probing for reconstruction of private embeddings
Tenant boundary violations — cross-tenant reads or writes in multi-tenant deployments

Neo4j, Kùzu, FalkorDB, Weaviate, Pinecone, and every other competitor leave the operator to build detection and response pipelines externally — or rely entirely on perimeter security.

How Purple8's SOC Agent Works

The SOC agent runs a two-layer detection pipeline on every metric observation — before any query or write is committed:

Layer 1 — Rule Engine (JourneyAnomalyRuleEngine): 11 stateless threshold rules covering all 10 threat classes. Fires in under 1 ms. SOC2-explainable — every signal carries rule_name, observed_value, and threshold. Zero warm-up.

Layer 2 — EWMA Statistical Baseline (JourneyAnomalyDetector): Per-tenant, per-metric Exponentially Weighted Moving Averages. Fires when the z-score exceeds 3.5σ. Adapts independently to each tenant's usage patterns — a tenant with legitimately large exports is not flagged once their baseline settles.

Signals from both layers are merged, classified into one of 10 ThreatClass values, and passed to the ContainmentManager for graduated response.

Containment — Graduated and Human-Gated

Level	Auto-released?	What Happens
SOFT	Yes	Flag + alert. No service disruption.
MEDIUM	Yes	Rate-limit + quarantine label. Journey continues under throttle.
HARD	No — human required	Writes suspended. Peer isolated. Named operator must call `release()`.
CRITICAL	No — human required	Tenant suspended. Tokens revoked. Emergency SST snapshot. Named operator must call `release()`.

ContainmentLevel.requires_human_release is True in code for HARD and CRITICAL. Anonymous releases (released_by="") raise ValueError. This is not a config option — it is enforced at the type level.

The Blast Radius Estimator

Before applying containment, BlastRadiusEstimator calculates how many tenants, journey instances, or SuperGraph peers could be affected — so operators see the scope before acting, and automated responses are proportionate.

Immutable SOC2-Aligned Audit Log

Every containment action and every release writes an AuditRecord — immutable, timestamped, and carrying actor, released_by, and released_at. The log maps directly to:

SOC2 Criterion	Purple8 Mechanism
CC6.6 — Anomaly detection	Layer 1 rules + Layer 2 EWMA z-score
CC6.7 — Privileged access	HARD/CRITICAL human-release gate enforced in code
CC7.3 — Incident response	`incident_report()` for SIEM/ticketing
CC9.2 — Business continuity	`EMERGENCY_SNAPSHOT` on CRITICAL

Competitive Gap

Capability	Neo4j	Kùzu	FalkorDB	Weaviate	Purple8
Built-in anomaly detection	❌	❌	❌	❌	✅ 2-layer (rules + EWMA)
Automated containment	❌	❌	❌	❌	✅ 4-tier graduated
Human-gated release for critical events	❌	❌	❌	❌	✅ Enforced in code
Immutable SOC2-aligned audit log	❌ external	❌	❌	❌	✅ Native `AuditRecord`
10 threat classes covered	❌	❌	❌	❌	✅
Blast radius estimation before containment	❌	❌	❌	❌	✅
SIEM / webhook callbacks	❌ external	❌	❌	❌	✅ Native
SOC Dashboard REST API	❌ external	❌	❌	❌	✅ `/soc/*` endpoints

Bottom line: No competitor ships a database-native SOC layer. Purple8's SOC agent removes an entire external toolchain (Datadog + PagerDuty + custom SIEM rules + custom release workflow) for teams operating in regulated or multi-tenant environments.

17. Operational & TCO Comparison

Deployment complexity

Step	Purple8	Weaviate + Neo4j (dual-stack)
Infrastructure services	1	2 (+ optional sync pipeline)
Docker containers	0	2+
Install command	`pip install purple8-hyper-graph`	`docker pull neo4j` + `docker pull semitechnologies/weaviate` + config
Write path	Single API call	Dual write to 2 DBs
Read path	In-process	2 network hops + client-side merge
Data drift risk	None	High (ETL lag between DBs)
Schema sync	N/A	Manual — changes in 2 places
Operational monitoring	1 endpoint	2+ endpoints + sync health

Cost of ownership

Cost Factor	Purple8	Weaviate Cloud + Neo4j AuraDB
SaaS monthly minimum	$0 (self-hosted)	$45/mo (Weaviate Flex) + $65+/mo (AuraDB) = $110+/mo
Dedicated managed	$0 (self-hosted)	$400+/mo (Weaviate Premium) + AuraDB
Infrastructure engineers	0 (single service)	1+ (dual-stack ops, sync pipeline maintenance)
Data drift incidents	0	Ongoing (dual-write race conditions)
Encryption licence	Built-in	Enterprise Edition required for Neo4j at-rest encryption
Document storage service	Included (node properties)	MongoDB Atlas $57+/mo or DynamoDB or Postgres RDS $25+/mo — eliminated by Purple8

18. Honest Gaps & Roadmap

A production-grade competitive analysis must be honest about limitations.

Knowledge synthesis (Task 3 — fan-out recall)

Purple8 scores 7.5/20 on knowledge synthesis vs 27.7/20 for combined Neo4j strategies. This is by design: Purple8 uses targeted hybrid queries; Neo4j uses breadth-first fan-out across all nodes. Fan-out wins on recall but at multi-second query cost. The trade-off is sub-1ms latency vs exhaustive recall.

Roadmap: Configurable fan-out depth with a latency budget parameter — trade latency for recall on a per-query basis.

Disambiguation latency at 100k (HNSW scan depth)

~~At 100k docs, disambiguation query latency reaches 3.6 s p50 due to HNSW scan depth.~~

✅ Fixed — no longer an open gap. Updated benchmark results will be published in the next cycle.

No managed cloud offering

Purple8 is currently self-hosted only. Teams requiring zero-ops managed service with SLA-backed uptime should consider Weaviate Cloud or Pinecone for their managed layer.

Roadmap: Managed cloud offering is on the product roadmap.

Published scale ceiling

The largest fully published benchmark is 100,000 documents. Internal testing exists for 1M-node graphs but has not been published.

Roadmap: 1M-node benchmark publication planned for the next benchmark cycle.

Rust Turbo core — separate build step

The Rust performance core requires maturin develop --release and is not included in the standard pip wheel.

Roadmap: Pre-compiled binary wheels for macOS arm64 and Linux x86_64 are planned — beginning with the private beta.

19. The "Force to Be Reckoned With" Case

Purple8 is not a prototype. As of v0.56.0:

✅ 0 known CVEs — pip-audit clean, post-remediation
✅ 182× faster than BM25 at 100k scale
✅ #1 MRR@10 on MS MARCO at every tested scale
✅ Unique category: the only Hyper Graph DB — graph + vector + document + full-text in one engine
✅ Unified Document Store — schemaless node properties replace MongoDB/DynamoDB/Postgres JSONB with no separate service and no sync layer
✅ Production hardening: BrickCore WAL, fdatasync durability, circuit breaker, AES-256-GCM
✅ Nightly CI regression gate: bench-sanity job blocks merge if add_node > 5 ms/op
✅ Dependabot + security CI job: pip-audit gates every PR before tests run
✅ 12 AEC domain modules — unique vertical with zero direct competition
✅ Native MCP server — no competitor ships this
✅ Journey Engine — graph-native AI workflow orchestration; no LangGraph + Airflow + Redis stack required
✅ Graph as Memory — immutable AI_ADVISED, ADVANCED_TO, HITL, SLA_BREACHED, and OUTCOME edges queryable in Cypher; no Mem0 / Zep / MemGPT required
✅ 39-model LLM registry, 9 providers — runtime model swap with no redeployment

Purple8 is the only database that can truthfully claim: "single pip install, unified graph + vector + document + full-text + AI orchestration, with built-in encryption and multi-tenancy, achieving #1 MRR@10 on MS MARCO at 100k scale with 182× lower latency than BM25."

No other product can make that statement.

20. Decision Framework

Use Case	Best Choice	Reason
RAG with entity disambiguation	Purple8	Only system achieving 1.000 disambiguation accuracy
Knowledge graph + vector unified queries	Purple8	Single engine, no dual-write, no ETL lag
Air-gapped / regulated / AEC deployment	Purple8	`pip install`, AES-256-GCM built-in, 5 KMS, AEC modules
Agent / MCP-native integration	Purple8	Only system with native MCP server
Temporal reasoning over events	Purple8	Vector-only DBs score 0.000 on temporal chains
Schemaless document storage	Purple8	Node `properties` dict — same engine, same encryption, same WAL; no MongoDB required
AI workflow orchestration (entity lifecycle)	Purple8 Journey	Graph-native state, SLA enforcement, HITL, immutable audit
Stateful AI workflows (replace LangGraph)	Purple8 Journey	Durable graph-edge state survives restarts
Business process automation with AI steps	Purple8 Journey	Per-entity SLA + AI advisor; Airflow has no entity model
AI agent memory (replace Mem0 / Zep / MemGPT)	Purple8	`AI_ADVISED` + `OUTCOME` edges in same graph — Cypher-queryable, vector-searchable, encrypted, no separate service
Regulated / multi-tenant security operations	Purple8	Built-in SOC agent — 2-layer detection, 4-tier containment, human-gated release, SOC2-aligned audit log
Full Cypher + APOC + GDS (50+ algorithms)	Neo4j	Mature, large ecosystem, full standards compliance
Pure ANN similarity search (no graph)	Qdrant / LanceDB	Purpose-built, high performance for vector-only
AWS-native zero-ops managed graph	Amazon Neptune	Managed, AWS-native
Globally-distributed transactional graph (GCP)	Spanner Graph	Paxos at global scale, stable schema
Managed cloud, zero-ops vector search	Pinecone / Weaviate	Fully managed SaaS with SLA guarantees
Offline ML feature store (columnar)	LanceDB	Lance format + DuckDB integration

21. Scoring Summary

Scale: 1 (weak) → 5 (best-in-class). Weighted for AI-first enterprise workloads.

Dimension	Weight	Purple8	Neo4j	Kùzu	FalkorDB
Graph query expressiveness	10%	4	5	5	4
Vector search capability	12%	5	2	2	2
Unified vector+graph query	12%	5	1	1	1
Built-in RAG pipeline	10%	5	1	1	1
Full-text search	5%	4	3	1	3
LLM / AI integration	12%	5	2	1	1
Enterprise security	10%	5	3	1	1
Deployment simplicity	8%	4	2	3	4
Scale & performance	8%	3	4	4	3
Document ingestion	5%	5	1	1	1
Maturity & ecosystem	8%	2	5	3	3
Weighted Score		4.18	2.62	2.04	2.08

Scoring context

These scores are weighted for AI-first enterprise workloads. For pure graph analytics, Neo4j's score would be significantly higher. The scores reflect Purple8's target buyer, not a universal ranking.

Appendix — Benchmark Methodology

Suite A uses synthetic data (64-dim embeddings) for reproducibility without network access
Suite B uses real all-MiniLM-L6-v2 embeddings (384-dim) on MS MARCO and HotpotQA subsets
Competitor results in Suite A are emulated via Purple8's strategy implementations (weaviate-strategy, neo4j-strategy, combined-strategy) running on the same local hardware — not live services. Competitor latency in those tests is therefore theoretical minimum, not live service latency
Benchmark hardware: Apple M-series (macOS dev baseline) for Suites C–J; m6i.2xlarge (8 vCPU, 32 GB RAM) for hybrid search tables
All p50/p95 latency values are end-to-end query latency in milliseconds, 3 runs per cell

Full reproducibility: Benchmarks

Comparative Analysis ​

What Category Is Purple8 In? ​

Executive Summary ​

1. Market Landscape ​

1.1 Category Map ​

1.2 Competitor Roster ​

2. Core Feature Matrix ​

3. Performance ​

Hybrid search (vector + graph, 100K nodes) ​

Pure graph traversal (100K nodes, 3-hop MATCH) ​

Search quality (MS MARCO MRR@10 — real sentence embeddings) ​

HotpotQA multi-hop reasoning ​

GraphRAG task accuracy (Suite A v2, 2,500 docs) ​

Write throughput & durability (Suite C, 100k nodes) ​

Document store query (Suite D, 100k nodes) ​

Multi-tenancy (Suite G, 10 tenants) ​

Encryption overhead (Suite F) ​

MCP server latency (Suite I) ​

4. Head-to-Head: Purple8 vs Neo4j + Vector Plugin ​

Where Neo4j wins ​

Where Purple8 wins ​

The disambiguation moat ​

5. Head-to-Head: Purple8 vs Kùzu ​

6. Head-to-Head: Purple8 vs FalkorDB ​

7. Head-to-Head: Purple8 vs Vector-Only DBs (Weaviate / Pinecone / Qdrant / LanceDB) ​

Accuracy comparison ​

Operational comparison ​

8. Head-to-Head: Purple8 vs Graph-Only DBs (Memgraph / Neptune / Cosmos Gremlin) ​

9. Head-to-Head: Purple8 vs Spanner Graph ​

10. Head-to-Head: Purple8 Journey vs AI Orchestration Frameworks ​

Architecture comparison ​

What Journey does that LangGraph cannot ​

What Journey does that Airflow cannot ​

What Journey does that CrewAI / AutoGen cannot ​

Journey capability summary ​

11. Graph as Memory — AI That Learns From Its Own History ​

What this is ​

What gets written automatically ​

Querying the memory (standard Cypher) ​

The learning loop (no retraining required) ​

Real-time memory via CDC ​

Competitor comparison — AI memory ​

What this is not ​

12. Unique Differentiators (Eight Moats) ​

Moat 1 — Entity Disambiguation (1.000 vs ≤ 0.500) ​

Moat 2 — Zero-Drift Architecture ​

Moat 3 — AES-256-GCM Envelope Encryption (Built-in, 5 KMS) ​

Moat 4 — Single pip install + Embedded Runtime ​

Moat 5 — AEC Vertical + DocIntel (56+ Formats) ​

Moat 6 — Journey Engine (Graph-Native AI Workflow Orchestration) ​

Moat 7 — Unified Document Store ​

Moat 8 — Graph as Memory (No External Memory Service) ​

13. RAG Studio — Built-In Pipeline with Model Registry & Evaluation ​

🔀 Multi-Index Router — RouterAgent (v0.31.0) ​

📄 Late Chunking — chunking_strategy: "late" (v0.31.0) ​

🔗 RRF Fusion — fusion_strategy: "rrf" (v0.31.0) ​

14. Agentic Chunking Intelligence & Multi-Model Index (v0.32.0) ​

The Problem: Single-Model Vector Spaces Degrade on Mixed Corpora ​

Architecture: ChunkingAgent + RouterAgent Close the Loop ​

Default Domain → Model Mapping ​

DocIntel Fast-Path vs Heuristic Classification ​

Per-Label Query Re-Embedding ​

Competitive Differentiator ​

15. SOC Agent — Built-in Security Operations (v0.33.0) ​

The Problem No Competitor Solves ​

How Purple8's SOC Agent Works ​

Containment — Graduated and Human-Gated ​

The Blast Radius Estimator ​

Immutable SOC2-Aligned Audit Log ​

Competitive Gap ​

17. Operational & TCO Comparison ​

Deployment complexity ​

Cost of ownership ​

18. Honest Gaps & Roadmap ​

Knowledge synthesis (Task 3 — fan-out recall) ​

Disambiguation latency at 100k (HNSW scan depth) ​

No managed cloud offering ​

Published scale ceiling ​

Rust Turbo core — separate build step ​

19. The "Force to Be Reckoned With" Case ​

Comparative Analysis

What Category Is Purple8 In?

Executive Summary

1. Market Landscape

1.1 Category Map

1.2 Competitor Roster

2. Core Feature Matrix

3. Performance

Hybrid search (vector + graph, 100K nodes)

Pure graph traversal (100K nodes, 3-hop MATCH)

Search quality (MS MARCO MRR@10 — real sentence embeddings)

HotpotQA multi-hop reasoning

GraphRAG task accuracy (Suite A v2, 2,500 docs)

Write throughput & durability (Suite C, 100k nodes)

Document store query (Suite D, 100k nodes)

Multi-tenancy (Suite G, 10 tenants)

Encryption overhead (Suite F)

MCP server latency (Suite I)

4. Head-to-Head: Purple8 vs Neo4j + Vector Plugin

Where Neo4j wins

Where Purple8 wins

The disambiguation moat

5. Head-to-Head: Purple8 vs Kùzu

6. Head-to-Head: Purple8 vs FalkorDB

7. Head-to-Head: Purple8 vs Vector-Only DBs (Weaviate / Pinecone / Qdrant / LanceDB)

Accuracy comparison

Operational comparison

8. Head-to-Head: Purple8 vs Graph-Only DBs (Memgraph / Neptune / Cosmos Gremlin)

9. Head-to-Head: Purple8 vs Spanner Graph

10. Head-to-Head: Purple8 Journey vs AI Orchestration Frameworks

Architecture comparison

What Journey does that LangGraph cannot

What Journey does that Airflow cannot

What Journey does that CrewAI / AutoGen cannot

Journey capability summary

11. Graph as Memory — AI That Learns From Its Own History

What this is

What gets written automatically

Querying the memory (standard Cypher)

The learning loop (no retraining required)

Real-time memory via CDC

Competitor comparison — AI memory

What this is not

12. Unique Differentiators (Eight Moats)

Moat 1 — Entity Disambiguation (1.000 vs ≤ 0.500)

Moat 2 — Zero-Drift Architecture

Moat 3 — AES-256-GCM Envelope Encryption (Built-in, 5 KMS)

Moat 4 — Single `pip install` + Embedded Runtime

Moat 5 — AEC Vertical + DocIntel (56+ Formats)

Moat 6 — Journey Engine (Graph-Native AI Workflow Orchestration)

Moat 7 — Unified Document Store

Moat 8 — Graph as Memory (No External Memory Service)

13. RAG Studio — Built-In Pipeline with Model Registry & Evaluation

🔀 Multi-Index Router — `RouterAgent` (v0.31.0)

📄 Late Chunking — `chunking_strategy: "late"` (v0.31.0)

🔗 RRF Fusion — `fusion_strategy: "rrf"` (v0.31.0)

14. Agentic Chunking Intelligence & Multi-Model Index (v0.32.0)

The Problem: Single-Model Vector Spaces Degrade on Mixed Corpora

Architecture: `ChunkingAgent` + `RouterAgent` Close the Loop

Default Domain → Model Mapping

DocIntel Fast-Path vs Heuristic Classification

Per-Label Query Re-Embedding

Competitive Differentiator

15. SOC Agent — Built-in Security Operations (v0.33.0)

The Problem No Competitor Solves

How Purple8's SOC Agent Works

Containment — Graduated and Human-Gated

The Blast Radius Estimator

Immutable SOC2-Aligned Audit Log

Competitive Gap

17. Operational & TCO Comparison

Deployment complexity

Cost of ownership

18. Honest Gaps & Roadmap

Knowledge synthesis (Task 3 — fan-out recall)

Disambiguation latency at 100k (HNSW scan depth)

No managed cloud offering

Published scale ceiling

Rust Turbo core — separate build step

19. The "Force to Be Reckoned With" Case