Quick Start
# Homebrew
brew tap --trust orneryd/nornicdb && brew install nornicdb && brew services start nornicdb
# arm64 / Apple Silicon
docker run -d --name nornicdb -p 7474:7474 -p 7687:7687 -v nornicdb-data:/data timothyswt/nornicdb-arm64-metal-bge:latest
# amd64 / CPU only
docker run -d --name nornicdb -p 7474:7474 -p 7687:7687 -v nornicdb-data:/data timothyswt/nornicdb-amd64-cpu-bge:latest
Open http://localhost:7474 for the admin UI. For NVIDIA CUDA hosts, use timothyswt/nornicdb-amd64-cuda-bge:latest. For Vulkan hosts, use timothyswt/nornicdb-amd64-vulkan-bge:latest.
Note: Docker on macOS does not expose Metal acceleration. The Apple Silicon image still runs, but GPU acceleration on macOS requires a native install from the releases page or a local build.
Writing queries? Start with the Hot-Path Cypher Cookbook — proven query shapes that route through the executor's specialized fast paths.
🤖 Building with Claude / agents? The docs/skills/ directory contains agent-ready skill files for every Cypher surface: query shapes, decay/promotion policies, managed embeddings, vector & hybrid search, and RAG procedures. Drop them into .claude/skills/ to make agents fluent in NornicDB.
What NornicDB Is
NornicDB is a graph database for workloads that need graph traversal, vector retrieval, and historical truth in the same system. It speaks Neo4j's language through Bolt and Cypher, exposes REST, GraphQL, and gRPC interfaces, and can preserve Qdrant-style client workflows where that helps migration.
The architecture draws from research in Temporal GraphRAG, agent memory systems, event-sourced decision memory, and persistence semantics for AI agents. These ideas appear in NornicDB as graph-native support for temporal facts, canonical knowledge versioning, replayable history, policy-driven memory retention, and audit-friendly retrieval.
It is built for knowledge systems, agent memory, Graph-RAG, and canonical truth stores where semantic search is only part of the query. The design goal is not to bolt a vector store onto a graph database. The design goal is one execution path for graph, vector, temporal, and audit-oriented workloads.
Why NornicDB Is Different
-
Neo4j-compatible by default: Bolt + Cypher support for existing drivers and applications.
-
Built for AI-native workloads: vector search, memory decay, and auto-relationships are first-class features.
-
Graph, vector, and ledger semantics in one engine: hybrid retrieval, graph traversal, canonical graph ledger modeling, tritemporal facts, as-of reads, txlog queries, and receipts do not require a second database.
-
Protocol flexibility without splitting the system: REST, GraphQL, Bolt/Cypher, Qdrant-compatible gRPC, and additive Nornic gRPC live on the same platform.
-
Hardware-accelerated execution: Metal/CUDA/Vulkan pathways for high-throughput graph + semantic workloads.
-
Operational flexibility: full images (models included), BYOM images, and headless API-only deployments.
Deployment Patterns
NornicDB is being used in internal production deployments for stack-consolidation workloads where graph traversal, vector retrieval, and auditability need to live in the same system.
-
Agent and Graph-RAG systems: replacing a Neo4j + Qdrant + embeddings stack with a single deployment for task tracking, dependency graphs, and retrieval pipelines.
-
Translation and evaluation workflows: replacing a document store plus embeddings pipeline with a single deployment for graph-native retrieval and faster aggregation paths.
Transactional Guarantees & Isolation
NornicDB implements Snapshot Isolation at the storage layer. Each transaction is anchored to a specific MVCC version, so point reads, label scans, and snapshot-visible graph traversals resolve against the same committed view of the graph.
-
Repeatable reads within a transaction: transactions see their own buffered writes, but not commits that land after their read snapshot.
-
Conflict detection at commit: concurrent graph mutations against the same logical state fail with a normalized
ErrConflictinstead of silently overwriting newer data. -
Explicit historical reads: MVCC pruning preserves the current head and a retained floor per logical key; requests below that retained floor fail safely with
ErrNotFound. -
Search remains current-state focused: current search paths are intentionally separate from historical MVCC state.
See transaction implementation details, historical reads and MVCC retention, and the canonical graph ledger guide.
Performance Snapshot
LDBC Social Network Benchmark (M3 Max, 64GB):
Query Type NornicDB Neo4j Speedup
Message content lookup 6,389 ops/sec 518 ops/sec 12x
Recent messages (friends) 2,769 ops/sec 108 ops/sec 25x
Avg friends per city 4,713 ops/sec 91 ops/sec 52x
Tag co-occurrence 2,076 ops/sec 65 ops/sec 32x
See full benchmark results for complete methodology and additional workloads.
Hybrid Retrieval Benchmarks
Hybrid retrieval is where NornicDB is materially different from vector-only stacks: the query shape is vector search followed by graph expansion in the same engine.
Local benchmark (67,280 nodes, 40,921 edges, 67,298 embeddings, HNSW CPU-only index):
Workload Transport Throughput Mean P50 P95 P99 Max
Vector only HTTP 19,342 req/s 511 us 470 us 750 us 869 us 1.02 ms
Vector only Bolt 22,309 req/s 444 us 428 us 629 us 814 us 968 us
Vector + 1 hop HTTP 11,523 req/s 859 us 699 us 1.54 ms 3.46 ms 4.71 ms
Vector + 1 hop Bolt 13,291 req/s 747 us 637 us 1.29 ms 3.24 ms 4.47 ms
Remote benchmark (GCP, 8 vCPU, 32 GB RAM):
-
Vector only: ~110.7 ms P50
-
Vector + 1 hop: ~112.9 ms P50
-
The delta between local and remote matched network RTT closely enough that end-to-end latency was network-bound rather than compute-bound.
This point is: once vector search plus one-hop traversal stays in low single-digit milliseconds locally, the bottleneck shifts from retrieval logic to deployment topology.
See the hybrid retrieval benchmark write-up for methodology, caveats, and reproduction queries, and see Graph-RAG: NornicDB vs Typical for the architectural implications.
🔬 Academic Validation: UCLouvain Case Study
NornicDB is currently being utilized by researchers at UCLouvain to map large-scale Cyber-Physical Systems (CPS).
In benchmarks performing *Automata Learning (L)**—a high-iteration logic process where an LLM acts as a "Deterministic Teacher" or Oracle—NornicDB outperformed industry-standard graph databases by a significant margin:
-
Efficiency: 2.2x Faster than Neo4j in total execution time for formal logic mapping.
-
Throughput: Successfully handled 1,443 state-transition queries in ~32 seconds (Avg 22.69ms