NornicDB: The 52x Faster Graph Database That Replaces Neo4j + Qdrant

What if your graph database could think in vectors, remember everything, and run on your GPU—without changing a single line of Cypher?

Stop duct-taping Neo4j to Qdrant. Stop paying the latency tax of cross-database joins. Stop pretending that "graph + vector" means two separate systems with fragile ETL pipelines between them.

There's a secret weapon emerging from the open-source trenches that top AI engineers are already deploying in production. It's called NornicDB—a distributed, low-latency graph and vector database with temporal MVCC, sub-millisecond HNSW search, and hardware acceleration across Metal, CUDA, and Vulkan. And here's the kicker: it speaks fluent Neo4j Bolt/Cypher and Qdrant gRPC, meaning your migration path is practically nonexistent.

The numbers are already insane. 52x faster than Neo4j on graph traversals. 25x faster on friend-network queries. Vector search plus one-hop graph expansion in under a millisecond locally. Academic researchers at UCLouvain clocked it at 2.2x faster than Neo4j for formal logic mapping with LLM-driven automata learning.

If you're building AI agents, Graph-RAG systems, or any knowledge architecture where relationships and semantics must coexist, you need to understand why developers are quietly abandoning their dual-database stacks. This is the deep dive that exposes what NornicDB actually does, how it achieves these speedups, and exactly how to deploy it today.

What Is NornicDB?

NornicDB is a graph database engineered for AI-native workloads that demand graph traversal, vector retrieval, and historical truth in a single execution engine. Created by Timothy Sweet and released as open source under the MIT license, it represents a fundamental architectural bet: that the future of intelligent systems requires fusing three traditionally separate data paradigms—property graphs, vector embeddings, and temporal versioning—without the complexity and latency of multiple databases.

The name itself signals ambition. "Psygnosis," the project's guiding concept, is a portmanteau of Greek "mind" (psyche) and "knowledge" (gnosis). NornicDB aims to be the substrate for systems that don't just store relationships, but understand them semantically and remember how they evolved.

Why it's trending now is no mystery. The explosion of Large Language Model applications has exposed a critical infrastructure gap. Retrieval-Augmented Generation (RAG) pipelines typically bolt vector databases onto graph stores, creating synchronization nightmares, query complexity, and latency that kills user experience. NornicDB collapses this stack. Its hybrid execution model—streaming fast paths for common patterns plus a general Cypher engine—means vector search followed by graph traversal executes in the same query plan, same process, same millisecond.

The project has gathered significant traction: 25,000+ Docker pulls, active Discord community, academic validation from UCLouvain researchers, and a rapidly maturing feature set that recently hit version 1.1.0. With multi-architecture support spanning CPU, NVIDIA CUDA, Apple Metal, and Vulkan, it's deployable everywhere from edge devices to cloud GPU instances.

Key Features That Separate NornicDB from the Pack

Neo4j-Compatible by Design, Not Afterthought

NornicDB implements the Bolt protocol and Cypher query language natively. This isn't a compatibility layer with caveats—it's wire-protocol compatible with existing Neo4j drivers in Python, JavaScript, Go, Java, and .NET. Your existing applications connect without code changes. Your Cypher skills transfer immediately. The migration cost drops from months to hours.

Sub-Millisecond Hybrid Retrieval

The database's signature capability is vector + graph execution in a single engine. Local benchmarks show vector-only queries at 19,342 req/s (HTTP) and 22,309 req/s (Bolt) with mean latencies of 444-511 microseconds. Add one graph hop—vector search then traverse relationships—and throughput holds at 11,523-13,291 req/s with P50 latencies of 637-699 microseconds. This is not theoretical; this is CPU-only HNSW with 67,298 embeddings on standard hardware.

Hardware-Accelerated Everywhere

Unlike databases that optimize for a single GPU vendor, NornicDB runs accelerated paths on Metal (Apple Silicon), CUDA (NVIDIA), and Vulkan (cross-platform). The Docker image matrix reflects this flexibility: ARM64 Metal images for Mac deployments, CUDA images for Linux GPU servers, CPU-only for minimal footprint, and headless variants for embedded microservices.

Temporal MVCC with Canonical Graph Ledger

Snapshot isolation at the storage layer means every transaction anchors to a specific version. You get repeatable reads, conflict detection at commit, explicit historical reads, and as-of queries without a separate time-series database. For compliance-heavy domains—financial systems, audit platforms, AI governance—this enables tritemporal fact modeling, non-overlapping validity enforcement, and receipt-hashed mutation logs natively.

Knowledge-Layer Scoring with Decay Profiles

Inspired by cognitive science, NornicDB implements the Ebbinghaus-Roynard four-layer decomposition for memory management. Operators define decay profiles with configurable half-lives, promotion policies that elevate stable facts, and visibility thresholds that suppress irrelevant data. This isn't hardcoded AI behavior—it's declarative Cypher DDL that you model for your domain.

Intelligent Auto-Relationships

The engine weaves connections automatically through embedding similarity, co-access patterns, temporal proximity, and transitive inference. Your knowledge graph grows organically as data is queried and stored, reducing manual curation overhead for agent memory and research tools.

Heimdall AI Assistant

A built-in AI assistant with natural language query capabilities, plugin system with lifecycle hooks, and autonomous database event monitoring. Enable it with a single environment variable and extend it with custom .so plugins.

Use Cases Where NornicDB Destroys the Competition

1. AI Agent Memory Systems

LLM agents need persistent, queryable, decaying memory. Traditional solutions stitch a vector database (for semantic recall) to a graph database (for relationship tracking) to a cache (for session context). NornicDB unifies this: vector search retrieves relevant memories, graph traversal follows agent-action chains, and decay profiles automatically suppress stale context. One database, one query, sub-millisecond response.

2. Graph-RAG for Production LLM Inference

Graph-RAG architectures—where retrieval combines semantic search with structured relationship traversal—typically require orchestrating multiple systems. NornicDB's hybrid retrieval executes vector search followed by graph expansion in the same engine. The benchmark data proves this isn't marginal: vector + 1 hop stays in low single-digit milliseconds locally, and remote deployments are network-bound, not compute-bound. Your RAG pipeline's latency floor drops dramatically.

3. Canonical Truth Stores and Compliance Platforms

Financial systems, RegTech, and AI governance require versioned facts with audit trails. NornicDB's canonical graph ledger model provides append-only mutation history, as-of reads for state reconstruction, and WAL-correlated receipt hashes. A loan risk system can query "what did we know, when did we know it" across tritemporal dimensions—assertion time, valid time, and transaction time—without ETL into a separate ledger database.

4. Research and Knowledge Graph Construction

UCLouvain's Cyber-Physical Systems research demonstrates NornicDB's academic viability. In Automata Learning (L*) benchmarks—where an LLM acts as deterministic teacher for formal logic mapping—NornicDB processed 1,443 state-transition queries in ~32 seconds versus Neo4j's 72 seconds. For researchers connecting papers, notes, and insights through semantic and structural relationships, this throughput advantage compounds across iterative discovery workflows.

5. Session Context and Conversational AI

Decaying conversation history with automatic relationship formation between topics, entities, and user intents. The knowledge-layer scoring ensures recent context surfaces immediately, while durable facts persist with conservative decay profiles.

Step-by-Step Installation & Setup Guide

Docker Deployment (Recommended)

NornicDB's Docker images are architecture-optimized and model-bundled for immediate use. Choose your platform:

# Apple Silicon with Metal GPU acceleration + BGE-M3 embeddings
docker run -d --name nornicdb \
  -p 7474:7474 -p 7687:7687 \
  -v nornicdb-data:/data \
  timothyswt/nornicdb-arm64-metal-bge:latest

# AMD64 with NVIDIA CUDA + BGE-M3 embeddings
docker run -d --name nornicdb \
  -p 7474:7474 -p 7687:7687 \
  -v nornicdb-data:/data \
  timothyswt/nornicdb-amd64-cuda-bge:latest

# AMD64 CPU-only for minimal footprint
docker run -d --name nornicdb \
  -p 7474:7474 -p 7687:7687 \
  -v nornicdb-data:/data \
  timothyswt/nornicdb-amd64-cpu-bge:latest

# Vulkan cross-platform GPU acceleration
docker run -d --name nornicdb \
  -p 7474:7474 -p 7687:7687 \
  -v nornicdb-data:/data \
  timothyswt/nornicdb-amd64-vulkan-bge:latest

Critical note for macOS users: Docker on macOS does not expose Metal acceleration through virtualization. The Apple Silicon image runs, but for true GPU acceleration on macOS, install natively from the releases page or build locally.

Access the admin UI at http://localhost:7474 and connect via Bolt at bolt://localhost:7687.

Build from Source

For custom builds, development, or platforms without Docker:

# Clone the repository
git clone https://github.com/orneryd/NornicDB.git
cd NornicDB

# Build the binary
go build -o nornicdb ./cmd/nornicdb

# Start the server
./nornicdb serve

Go 1.26+ is required. The Makefile provides additional targets:

make build              # Standard build
make build-headless     # No web UI, smaller binary
make build-localllm     # With local LLM support
make build-all          # All variants for current architecture

Configuration File Setup

Create nornicdb.yaml for production deployments:

server:
  bolt_port: 7687
  http_port: 7474
  host: localhost

database:
  data_dir: ./data
  async_writes_enabled: true
  async_flush_interval: 50ms
  async_max_node_cache_size: 50000
  async_max_edge_cache_size: 100000

embedding:
  enabled: true
  provider: local        # Options: local, ollama, openai
  model: bge-m3.gguf
  url: ""
  dimensions: 1024

embedding_worker:
  chunk_size: 8192
  chunk_overlap: 50

memory:
  decay_enabled: true
  decay_interval: 3600
  auto_links_enabled: true
  auto_links_similarity_threshold: 0.82

Headless Deployment

For microservices and API-only use cases:

# Runtime flag
nornicdb serve --headless

# Environment variable
NORNICDB_HEADLESS=true nornicdb serve

# Or use headless Docker image
docker run -d -p 7474:7474 -p 7687:7687 \
  -v nornicdb-data:/data \
  timothyswt/nornicdb-amd64-cpu-headless:latest

REAL Code Examples from NornicDB

Example 1: Drop-In Neo4j Driver Connection

The most powerful migration feature is invisible—your existing Neo4j code just works:

from neo4j import GraphDatabase

# Standard Neo4j driver connects to NornicDB without modification
driver = GraphDatabase.driver("bolt://localhost:7687")

with driver.session() as session:
    # Create a node with vector-embeddable content
    session.run("CREATE (n:Memory {content: 'Hello NornicDB'})")
    
    # Query it back
    result = session.run("MATCH (n:Memory) RETURN n.content")
    for record in result:
        print(record["n.content"])  # "Hello NornicDB"

What's happening here: NornicDB's Bolt protocol implementation is wire-compatible with Neo4j's. The Python neo4j driver negotiates Bolt handshake, sends Cypher, and receives results exactly as it would from a Neo4j server. No driver swap. No connection string changes. No query rewrites for supported shapes.

Example 2: Declarative Decay Profiles for Agent Memory

This is where NornicDB diverges from every graph database on the market. Define cognitive-inspired memory management in pure Cypher:

-- Create a reusable decay profile with 7-day half-life
CREATE DECAY PROFILE working_memory OPTIONS {
  halfLifeSeconds: 604800,      -- 7 days in seconds
  function: 'exponential',       -- Exponential decay curve
  visibilityThreshold: 0.10      -- Suppress below 10% relevance
}

-- Apply profile to specific node labels with overrides
CREATE DECAY PROFILE session_retention
FOR (n:SessionRecord)
APPLY {
  DECAY PROFILE 'working_memory'
  n.tenantId NO DECAY           -- Tenant IDs remain permanently visible
}

-- Query with dynamic relevance scoring
MATCH (n:SessionRecord) WHERE decayScore(n) > 0.5
RETURN n ORDER BY decayScore(n) DESC

The technical depth: This isn't a hardcoded AI feature. NornicDB parses CREATE DECAY PROFILE as Cypher DDL, persists profile definitions to system catalogs, and evaluates decayScore() at query time against the transaction's MVCC snapshot. The NO DECAY override for tenantId demonstrates label-property granularity. The engine supports exponential, linear, and custom decay functions, with promotion policies that can elevate stable facts to longer-lived tiers.

Example 3: Hybrid Vector + Graph Search via Cypher

Native vector search through the familiar Cypher CALL procedure interface:

-- Vector semantic search returning top-10 matches
CALL db.index.vector.queryNodes('embeddings', 10, 'machine learning guide')
YIELD node, score
RETURN node.content, score

Behind the scenes: NornicDB maintains HNSW (Hierarchical Navigable Small World) indexes for vector data, with GPU-accelerated construction and querying. The 'embeddings' index name is user-defined; 10 is the top-k; 'machine learning guide' is the query text that gets embedded through the configured model (default: BGE-M3). The YIELD clause exposes the scored node and similarity score for further Cypher processing—filter, traverse, aggregate, all in one query.

Example 4: REST API Hybrid Search

For microservices and polyglot environments:

# Hybrid search combining vector similarity with full-text signals
curl -X POST http://localhost:7474/nornicdb/search \
  -H "Content-Type: application/json" \
  -d '{
    "query": "machine learning",
    "limit": 10,
    "hybrid": true           # Enables vector + BM25 fusion
  }'

Architecture note: This endpoint routes through NornicDB's HTTP layer to the same hybrid execution engine that serves Bolt requests. The optional hybrid flag engages BM25-seeded vector reranking—a technique where lexical matching guides semantic retrieval, reducing the "lost in embedding space" problem for domain-specific terminology.

Example 5: Enabling Heimdall AI Assistant

# Start with AI assistant enabled
NORNICDB_HEIMDALL_ENABLED=true ./nornicdb serve

Then interact via natural language:

• "Get the database status"
• "Show me system metrics"
• "Run health check"

Plugin architecture: Heimdall supports custom actions through .so plugins with lifecycle hooks (PrePrompt, PreExecute, PostExecute). The assistant monitors database events for autonomous actions and delivers inline notifications with guaranteed ordering—critical for agent systems that must observe state changes in causal sequence.

Advanced Usage & Best Practices

Parser Mode Switching for Performance vs. Correctness

NornicDB runs two Cypher parser paths: the default nornic parser optimized for low-overhead hot-path routing, and antlr mode for strict parsing and diagnostics. Internal benchmarks show large overhead differences on certain query shapes when full parse-tree paths are used. Production deployments should default to nornic; enable antlr only for debugging and validation workflows.

HNSW Construction Optimization

The published 2.7x HNSW build speedup—reducing 1M embedding index construction from ~27 minutes to ~10 minutes—comes from BM25-seeded insertion ordering. By extracting lexical seeds and using them to guide HNSW insertion sequence, traversal waste during construction drops dramatically without modifying core quality parameters. The same seed strategy improves k-means centroid initialization for vector pipeline efficiency.

GPU-Accelerated Path Selection

For CUDA deployments, ensure your Docker runtime exposes the GPU:

docker run --gpus all -d ... timothyswt/nornicdb-amd64-cuda-bge:latest

For Apple Silicon native builds, verify Metal availability through system logs. The engine gracefully falls back to CPU SIMD paths when GPU kernels fail to compile.

Memory Decay Tuning

Start with auto_links_enabled: true and auto_links_similarity_threshold: 0.82, then adjust threshold based on your domain's semantic density. Higher thresholds (0.90+) reduce false-positive relationships in precise domains; lower thresholds (0.70-) increase connectivity for exploratory research tools.

Retention Policy Caution

Retention policies are disabled by default and must be explicitly enabled. When activated, they support label-aware evaluation, legal holds, and GDPR erasure tracking. Enable only after reviewing the retention policies documentation to avoid unintended data loss.

Comparison with Alternatives

Why NornicDB wins: It's the only platform that combines native graph traversal, vector search, temporal versioning, and audit receipts in a single engine with drop-in Neo4j compatibility. Competitors force architectural compromises: Neo4j lacks integrated vector ledger semantics; Qdrant has no graph native capabilities; QLDB isn't graph-structured. NornicDB's protocol flexibility—Bolt, REST, GraphQL, Qdrant-compatible gRPC, and native Nornic gRPC—means you don't rebuild client infrastructure to adopt it.

FAQ

Is NornicDB a true drop-in replacement for Neo4j?

For supported Cypher query shapes and Bolt protocol operations, yes. Existing Neo4j drivers connect without modification. Complex Neo4j-specific extensions may require review—check the Neo4j migration guide for feature parity details.

How does GPU acceleration work? Can I use it with my existing hardware?

NornicDB supports Metal (Apple Silicon), CUDA (NVIDIA), and Vulkan (cross-platform). Select the appropriate Docker image for your hardware. CPU-only fallback with SIMD optimization is always available. Note that Docker on macOS cannot expose Metal—use native builds for Apple GPU acceleration.

What's the performance cost of temporal MVCC?

Minimal for current-state queries. NornicDB intentionally separates current search paths from historical MVCC state. Point reads, label scans, and snapshot-visible traversals resolve against committed views with repeatable read isolation. Historical queries below the retained floor fail safely with ErrNotFound.

Can I migrate from Qdrant without rewriting my application?

Yes. NornicDB preserves Qdrant-style gRPC workflows through protocol compatibility. Your existing Qdrant client code can target NornicDB's gRPC endpoint while you incrementally adopt graph-native capabilities.

Is NornicDB production-ready?

The project reports internal production deployments for stack-consolidation workloads. Version 1.1.0 is released with comprehensive benchmarks, academic validation, and active community support. As with any database adoption, validate against your specific workload patterns before full production cutover.

How does the knowledge-layer scoring differ from simple TTL?

TTL (time-to-live) is binary: data exists or it's deleted. NornicDB's decay profiles provide continuous relevance scoring with configurable curves, promotion policies that elevate stable facts, and visibility thresholds that suppress without destroying. It's inspired by human memory models, not cache expiration.

What embedding models are supported?

The standard images include BGE-M3 (1024 dimensions). BYOM (Bring Your Own Model) images accept any GGUF-format model mounted at /app/models. External providers (Ollama, OpenAI) are configurable via the embedding configuration section.

Conclusion

NornicDB represents something rare in database engineering: a genuine architectural unification that doesn't sacrifice compatibility for innovation. By fusing graph traversal, vector search, and temporal versioning into one engine—with GPU acceleration, cognitive-inspired memory management, and wire-protocol compatibility with both Neo4j and Qdrant—it eliminates the stack complexity that slows AI-native application development.

The benchmarks are not marginal improvements; they're order-of-magnitude wins that change what's possible in latency-sensitive systems. The 52x speedup on graph traversals, sub-millisecond hybrid retrieval, and 2.2x faster formal logic mapping aren't marketing numbers—they're reproducible results from published methodologies.

For teams currently maintaining separate Neo4j and Qdrant deployments, the operational simplification alone justifies evaluation. For teams building agent memory, Graph-RAG, or canonical truth stores, NornicDB may be the only database that actually fits the problem.

Get started now: Pull the Docker image for your platform, connect with your existing Neo4j driver, and experience what happens when graph, vector, and temporal truth finally live in one system.

⭐ Star the repository: https://github.com/orneryd/NornicDB

📖 Full documentation: https://orneryd.github.io/NornicDB/

💬 Join the community: Discord

The future of intelligent data infrastructure isn't more databases—it's smarter ones. NornicDB is already here.