by orneryd
Nornicdb is a distributed low-latency, Graph+Vector, Temporal MVCC with all sub-ms HNSW search, graph traversal, and writes. Using Neo4j Bolt/Cypher and qdrant's gRPC means you can switch with no changes. Then, adding intelligent features like schemas, managed embeddings, LLM reranking+inferrence, GPU accel, Auto-TLP, Memory Decay, and MCP server.
# Add to your Claude Code skills
git clone https://github.com/orneryd/NornicDBGuides for using mcp servers skills like NornicDB.
Last scanned: 5/7/2026
{
"issues": [],
"status": "PASSED",
"scannedAt": "2026-05-07T06:37:58.463Z",
"semgrepRan": false,
"npmAuditRan": true,
"pipAuditRan": true
}No comments yet. Be the first to share your thoughts!
# 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.
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.
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.
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.
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.
ErrConflict instead of silently overwriting newer data.ErrNotFound.See transaction implementation details, historical reads and MVCC retention, and the canonical graph ledger guide.
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 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):
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.
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:
| DATABASE | CALLS | AVG TIME (ms) | TOTAL (s) | | ------------ | -------- | ------------- | --------- | | NornicDB | 1443 | 22.69 | 32.74 | | Neo4j | 1443 | 50.20 | 72.43 |