NornicDB: Neo4j-compatible graph plus vector search with MVCC history
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 while adding intelligent features like schemas, managed embeddings, reranking+llm, GPU accel, Auto-TLP, Policy-based Memory Decay, and MCP server.
At a glance
- What is it?
- NornicDB is a Go graph database that speaks Bolt and Cypher, adds Qdrant-compatible gRPC vector search and HNSW indexing, and keeps historical reads through MVCC snapshot isolation. It targets teams consolidating a graph database, a vector store and an embeddings pipeline into one process.
- Who is it for?
- Adopt NornicDB if you already write Cypher and want graph traversal, vector retrieval and as-of reads served by one process, and you are willing to run a young project that had no release before the 1.2.x line. Do not adopt it if you need a mature operational story, a published durability or recovery guarantee, or a client that only speaks the official Neo4j or Qdrant SDKs beyond the documented surfaces.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly Go, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The stack NornicDB is trying to replace
The problem is stack sprawl in retrieval systems. A typical Graph-RAG deployment runs a graph database for relationships, a separate vector store for embeddings, an embedding service, and often a document store for the source text. Every hop between them is a place where a query has to be split, joined in application code, and reconciled against a different consistency model. NornicDB's stated goal is one execution path for graph, vector, temporal and audit-oriented workloads, rather than bolting a vector index onto a graph engine. The README frames the target as knowledge systems, agent memory, Graph-RAG and canonical truth stores where semantic search is only part of the query. Two deployment patterns are named: agent and Graph-RAG systems replacing a Neo4j plus Qdrant plus embeddings stack, and translation or evaluation workflows replacing a document store plus embeddings pipeline. The audience is therefore engineers who already have a Cypher workload and a vector workload and are paying the integration cost between them, not someone shopping for a first database.
What the compatibility claims actually cover
Compatibility is the load-bearing part of the pitch, so it is worth being precise about what the material supports. The README claims Neo4j-compatible by default through Bolt and Cypher, so existing drivers and applications keep working, and it exposes REST, GraphQL and gRPC interfaces on the same platform. Qdrant compatibility is described as preserving Qdrant-style client workflows where that helps migration, delivered over Qdrant's gRPC surface, with an additive Nornic gRPC alongside it. That is a narrower claim than full parity with either product. The README does not publish a Cypher coverage matrix or a list of Qdrant RPCs that are implemented, so the honest position is that you should test your own query set rather than assume your application ports unchanged. The same caution applies to driver behaviour: Bolt compatibility in practice means the wire protocol and the query language, and the project does not document which driver versions have been exercised.
MVCC, snapshot isolation and the retained floor
The transactional model is the most concretely specified part of the project. 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. Transactions see their own buffered writes but not commits that land after their read snapshot. Concurrent mutations against the same logical state fail at commit with a normalized ErrConflict rather than silently overwriting newer data. That is a real design decision with a real cost: write conflicts surface as errors your application must retry, and the README does not describe an automatic retry helper. Historical reads are explicit. MVCC pruning preserves the current head and a retained floor per logical key, and requests below that retained floor fail safely with ErrNotFound. So history is bounded by a retention policy you configure, not unbounded, and a query that reaches past the floor gets a not-found rather than a stale answer. One boundary is stated plainly: search paths are intentionally separate from historical MVCC state, meaning vector search is current-state focused and does not read as of a past version. If your requirement is historical semantic search, this design does not offer it.
Getting an instance running and what the ports mean
The README gives three install paths. Homebrew: brew tap --trust orneryd/nornicdb && brew install nornicdb && brew services start nornicdb. On Apple Silicon, docker run -d --name nornicdb -p 7474:7474 -p 7687:7687 -v nornicdb-data:/data timothyswt/nornicdb-arm64-metal-bge:latest. On amd64 without a GPU, the same command with timothyswt/nornicdb-amd64-cpu-bge:latest. CUDA hosts use timothyswt/nornicdb-amd64-cuda-bge:latest and Vulkan hosts use timothyswt/nornicdb-amd64-vulkan-bge:latest. Port 7474 serves the admin UI at http://localhost:7474 and 7687 is the Bolt port, matching Neo4j's conventional layout. The image tags carry a bge suffix, which indicates the full images ship embedding models; the README also mentions BYOM images and headless API-only deployments as alternatives, which is the path to take if you supply your own models or want a smaller container. One platform caveat is stated directly: Docker on macOS does not expose Metal acceleration, so the Apple Silicon image runs but GPU acceleration there requires a native install from the releases page or a local build. The README also points query authors at docs/performance/hot-path-query-cookbook.md, described as proven query shapes that route through the executor's specialized fast paths. That document existing at all is a signal: query shape affects whether you hit an optimized path, so porting queries without reading it may leave performance on the table.
Agent tooling and the skills directory
NornicDB ships agent-facing material rather than leaving integration to the reader. The docs/skills/ directory contains skill files covering query shapes, decay and promotion policies, managed embeddings, vector and hybrid search, and RAG procedures, and the README says dropping them into .claude/skills/ makes agents fluent in NornicDB. There is also an MCP server listed among the features and topics. For teams building agent memory on top of the database, that is a lower-friction starting point than writing tool schemas from scratch. The caveat is that these files are documentation artifacts tied to a fast-moving codebase. With releases landing within days of each other in the 1.3.x line, skill files can describe a surface that has since changed. Treat them as a starting template to validate against the running instance, not as a specification.
Where the design gets in your way
Three limitations follow from the material. First, search and history are deliberately separate. Snapshot isolation gives you repeatable reads and as-of graph traversal, but vector search reads current state only. Systems that need to ask what the embedding index looked like last week cannot use this engine's MVCC for that question. Second, conflict handling is pushed to the caller. ErrConflict at commit is the correct behaviour under snapshot isolation, but the README describes detection, not resolution. High-contention write patterns on the same logical keys will need retry logic you write yourself. Third, the project is young. The listed releases run from v1.2.3 in August 2026 to v1.3.1 in September 2026, and the README describes internal production deployments rather than a broad published install base. The README does not document backup and restore procedures, upgrade paths between versions, or recovery behaviour after an unclean shutdown, and those are the questions that decide whether a database is safe to run. The multi-arch image matrix is also a maintenance surface: CPU, CUDA, Metal and Vulkan variants mean more images to track and more chances for one variant to lag. If you need a database with a decade of operational documentation behind it, this is the wrong tool today.
The alternative and the actual difference
The obvious alternative is running Neo4j for the graph and Qdrant for vectors, which is the stack NornicDB says it replaces. The difference is not feature count, it is where the join happens. In the two-database arrangement, a hybrid query means issuing a Cypher traversal to Neo4j, issuing a vector search to Qdrant, and combining the results in application code, with two consistency models to reason about and two systems to back up. NornicDB puts both behind one execution path with one MVCC version anchoring the reads. That buys consistency and removes a network hop, and it costs you the option of scaling the graph and vector tiers independently, plus the maturity of two widely deployed systems. A second alternative is a single-store approach using PostgreSQL with pgvector and a relational adjacency model. That keeps one system and one transaction, but recursive CTEs replace Cypher, and you lose Bolt driver compatibility, which is the main reason to consider NornicDB in the first place. The choice reduces to how much you value keeping existing Cypher clients and how much you value independent scaling of the vector tier.
Maintenance cost, releases and the MIT licence
Maintenance cost here has two components. The first is release cadence. Versions v1.2.3, 1.3.0 and v1.3.1 arrived within roughly three weeks of each other, each with a codename. That pace means upgrade testing is a recurring task, and the README does not describe a migration procedure or a compatibility policy between minor versions. Pin an image tag and test before moving. The second is the image matrix. Full images bundle embedding models, and there are separate CPU, CUDA, Metal and Vulkan builds, so your upgrade checklist depends on which variant you run. The repository is MIT licensed, which is permissive and places few obligations on how you distribute software that uses it. The licence identifier covers the project code; it does not automatically settle the terms of the embedding models shipped inside the bge-tagged images, which may carry their own licences from their upstream publishers. That is worth confirming with whoever owns licence review before you ship a container, and it is not a question this article can answer for you. The README does not state a support policy, a release support window, or a commercial offering, so plan on community channels for questions.
Editorial conclusion
Adopt NornicDB if you already write Cypher and want graph traversal, vector retrieval and as-of reads served by one process, and you are willing to run a young project that had no release before the 1.2.x line. Do not adopt it if you need a mature operational story, a published durability or recovery guarantee, or a client that only speaks the official Neo4j or Qdrant SDKs beyond the documented surfaces. Before committing, verify three things against your own data: that your existing Bolt driver connects and your Cypher parses, that a hybrid query returns the vector and graph results you expect, and that your licence position on the bundled BGE embedding models is acceptable for the images you pull.
Community notes