NornicDB

Production Deployment Patterns

NornicDB is currently deployed internally at CVS. The current deployment patterns are not theoretical migration slides; they are active stack consolidation projects.

• Parallel workload systems: replacing a Neo4j + Qdrant + OpenAI stack with a single Docker deployment to manage and track tasks and dependencies of LLM swarms and automated graph-rag retreival pipleines and the pipelines themselves. Performance timing varies on application structure and load. However, distribution is broad enough that I am actively and reliably hitting edge cases in production, cover those cases and hit a broad breadth of queries-in-production I actively test with.
• LLM translation quality systems: replacing a Mongo Atlas plus Azure embeddings pipeline stack with a single Docker deployment to improve the quality and speed of LLM-generated translations. (Mongo Atlas aggregation queries replaced with node labels + edges dropping vector search + aggregation query time from ~1s to ~1.6ms)

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

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 per full reasoning loop).

| DATABASE | CALLS | AVG TIME (ms) | TOTAL (s) | | ------------ | -------- | ------------- | --------- | | NornicDB | 1443 | 22.69 | 32.74 | | Neo4j | 1443 | 50.20 | 72.43 |

What Recent Deep-Dives Show

• Hybrid execution model (streaming fast paths + general engine): NornicDB uses shape-specialized streaming executors for common traversal/aggregation patterns while retaining a general Cypher path for coverage and correctness.
• Runtime parser mode switching: the default nornic parser is optimized for low-overhead hot-path routing, while antlr mode prioritizes strict parsing and diagnostics when debugging and validation