NornicDB

NornicDB

Graph, vector, and historical truth in one database Neo4j-compatible • Hybrid graph + vector retrieval • Historical reads via MVCC Achieving Psygnosis for AI

Multi-arch support: CPU | CUDA | Metal | Vulkan

Quick Start • What It Is • Why NornicDB • Benchmarks • Features • Docs • Comparison • Contributors

Quick Start

# Homebrew
brew tap 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 ErrConflict instead 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

Northwind benchmark (M3 Max, 64 GB; 48,000 products and 48,000 orders; 10 measured iterations after 2 warmups):

Metric	NornicDB	Neo4j	Difference
Overall mean query latency	0.23 ms	98.64 ms	-99.8% (432.38x ratio)
Overall throughput	17.70 ops/s	7.76 ops/s	+128.1% (2.28x)
Benchmark wall-clock	14.00 s	31.63 s	-55.7% (2.26x ratio)
E