NornicDB: a Neo4j-compatible graph database with vector search and MVCC history

The stack consolidation NornicDB is aimed at

NornicDB is a single Go binary that answers Neo4j's Bolt protocol and Cypher dialect, exposes REST, GraphQL and gRPC, and also speaks Qdrant's gRPC API. The README frames the target workload as knowledge systems, agent memory, Graph-RAG and canonical truth stores where semantic search is only part of the query. The stated design goal is one execution path for graph, vector, temporal and audit-oriented workloads, rather than a vector index bolted onto a graph store.

That framing matters because the usual alternative is three moving parts: a graph database, a vector database, and a service that generates embeddings and stitches results together. The README describes deployments where that trio is replaced by one deployment for task tracking, dependency graphs and retrieval pipelines, and another for translation and evaluation workflows. The project says these are internal production deployments, not published case studies, so treat the operational claims as unverified.

The audience is narrow on purpose. If your queries are pure key-value lookups or pure nearest-neighbour search with no relationships, the graph half of NornicDB is dead weight and a plain vector store will be simpler to run. The interesting case is when a query needs both: traverse a dependency graph, filter by a temporal fact, and rank candidates by embedding similarity in one round trip.

How graph, vector and MVCC share one engine

The storage layer implements Snapshot Isolation over MVCC. Each transaction is anchored to a specific MVCC version, so point reads, label scans and snapshot-visible graph traversals all resolve against the same committed view. A transaction sees its own buffered writes but not commits that land after its read snapshot, which gives repeatable reads inside the transaction. Concurrent mutations against the same logical state fail at commit with a normalized ErrConflict rather than overwriting newer data.

Historical reads are explicit. MVCC pruning keeps the current head plus a retained floor per logical key; a request below that floor fails with ErrNotFound instead of returning a stale or partial answer. That is a deliberate safety choice and also a real constraint: how far back you can read depends on the pruning configuration, and the README does not document how to tune that floor.

The README states that search paths stay current-state focused and are intentionally separate from historical MVCC state. So you can ask what the graph looked like at a past version, but the vector index is not a time machine. If you need historical semantic search, you have to reconstruct it from the versioned graph yourself.

The dependency list in go.mod backs the architecture up: Badger v4 for the key-value layer, gqlgen for GraphQL, the official Neo4j Go driver and Qdrant Go client for protocol compatibility, and yzma for local model execution. The module declares go 1.26.4.

Installing NornicDB and running a first Cypher query

The README gives Homebrew as the shortest path on macOS. The tap is explicitly trusted in the command, which is worth noticing: Homebrew will not install from an untrusted third-party tap without that flag.

brew tap --trust orneryd/nornicdb && brew install nornicdb && brew services start nornicdb

After the service starts, the admin UI is served on port 7474. On Linux or in a container, the README offers architecture-specific images. The amd64 CPU-only image is the safe default when you have no GPU:

docker run -d --name nornicdb -p 7474:7474 -p 7687:7687 -v nornicdb-data:/data timothyswt/nornicdb-amd64-cpu-bge:latest

Port 7687 is the Bolt endpoint, so any Neo4j driver pointed at localhost:7687 should connect. The repository's docker-compose.yml also publishes 7473 for the native HTTPS API and 6334 for the Qdrant gRPC compatibility endpoint, and passes configuration through NORNICDB_* environment variables such as NORNICDB_DATA_DIR, NORNICDB_BOLT_PORT and NORNICDB_NO_AUTH.

One caveat from the README: the compose defaults set NORNICDB_NO_AUTH to true. That is convenient for a laptop and unacceptable for anything reachable from a network. Set NORNICDB_AUTH and the related JWT and OAuth variables before you expose the ports.

The README points query authors at the Hot-Path Cypher Cookbook under docs/performance, which documents query shapes that route through the executor's specialized fast paths. That is a strong hint that Cypher written in a different shape will still run but will not take the fast path.

Where NornicDB is the wrong tool

The compatibility claims are the compatibility claims of a young project, not a guarantee. The README says Neo4j-compatible by default and the go.mod pulls in the official Neo4j Go driver, but nothing describes a conformance suite or lists unsupported Cypher clauses. If your application leans on a specific procedure, APOC surface or planner hint, budget time to test it rather than assuming parity.

The project is also single-binary by design. The README describes distributed characteristics in the project description, but the documentation covers snapshot isolation, conflict detection and MVCC pruning at the storage layer, not replication, quorum or failover. There is no documented clustering story to evaluate, and no operational runbook for splitting or rebalancing a dataset. Teams that need horizontal write scaling should look elsewhere until that gap is filled.

Finally, the accelerator story is uneven. The README states plainly that Docker on macOS does not expose Metal, so the Apple Silicon image runs without GPU acceleration there; GPU on macOS requires a native install from the releases page or a local build. That is a real deployment constraint, not a footnote.

NornicDB compared with Neo4j plus Qdrant

The obvious alternative is exactly the stack NornicDB replaces: Neo4j for the graph and Cypher, Qdrant for vectors, and a service in between that embeds text and merges the two result sets. That combination is mature. Neo4j has years of tooling, drivers, monitoring integrations and documentation; Qdrant has its own filtering and payload model. You get two systems to operate, two backup procedures and a consistency question every time a node is written to one store and its embedding to the other.

NornicDB's difference is that both live behind one commit boundary. Because the vector index and the graph share the MVCC storage layer, a write that changes a node and its embedding is one transaction, and a snapshot read sees a consistent pair. The README also claims managed embeddings, reranking with an LLM, policy-based memory decay and Auto-TLP as first-class features, plus an MCP server for agent tooling. Those are the features that make the consolidation argument, and they are also the ones with the least documentation in the README itself.

The trade is ecosystem versus coherence. Neo4j plus Qdrant gives you two well-documented systems and a synchronization problem you own. NornicDB gives you one system with a smaller surface of documentation and a much smaller community.

Licence, releases and upgrade cost

NornicDB is MIT licensed, with LICENSE.md in the repository root. MIT is permissive: it allows commercial use, modification and redistribution provided the copyright notice and licence text are retained. The repository also ships NOTICES.md and PATENTS.md, and go.mod pulls in dependencies under their own licences, including cloud KMS clients and the Badger key-value store. If you redistribute a built image, read those files rather than assuming MIT covers the whole artifact. This is not legal advice; get a lawyer to review anything you ship.

The release cadence is quick. The repository lists v1.3.1 (Feather) on 2026-09-08, 1.3.0 (Low Rider) on 2026-09-05 and v1.2.3 (ABC) on 2026-08-20. That is three releases in under three weeks, and the last push to main was on 2026-09-09. Fast iteration on a storage engine means schema and on-disk format questions deserve attention before an upgrade. The README does not document a migration path, a format version, or a rollback procedure, so the practical upgrade cost is unknown from what the project publishes. Snapshot your data directory before moving between minor versions, and pin an image tag rather than tracking latest.

What to check before you commit

Start with the two error paths, because they define the contract. Write a test that commits two conflicting transactions and confirm you get ErrConflict rather than a silent last-writer-wins. Then read below the retained MVCC floor and confirm ErrNotFound. If your application cannot tolerate either behaviour, you have found the boundary early.

Second, measure your own query shapes against the cookbook in docs/performance. The README's benchmark section is a project-published snapshot, and this article makes no performance claim from it. The honest test is your traversal pattern, your embedding dimension and your write mix.

Third, confirm the image matches your hardware. amd64-cuda, amd64-vulkan, arm64-metal and amd64-cpu variants exist, and the README's note about Metal under Docker on macOS is the kind of detail that wastes a day if you miss it. The docs/skills directory is also worth a look if agents will write queries against the database; the README describes dropping those files into .claude/skills/.

Editorial conclusion

Adopt NornicDB if you already write Cypher against Neo4j or Qdrant gRPC clients and want vector retrieval and versioned reads in the same process; skip it if you need a large third-party tool ecosystem or a documented multi-node cluster. Before committing, verify the retained MVCC floor behaviour with ErrConflict and ErrNotFound, and confirm a native image exists for your accelerator, because Docker on macOS does not expose Metal.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. orneryd/NornicDB on GitHub
4. README
5. Releases