A single graph+vector+temporal database for AI workloads — Neo4j-compatible, sub-millisecond hybrid search, and built-in memory decay.
NornicDB is a purpose-built graph database written in Go that unifies graph traversal, vector retrieval, and historical truth in a single engine. It speaks Neo4j’s Bolt protocol and Cypher query language natively, meaning existing Neo4j drivers and applications connect without modification, while gaining vector search, temporal MVCC reads, and AI-native knowledge management features that Neo4j does not provide.
The project emerged from a common AI architecture problem: knowledge-intensive applications — agents, Graph-RAG pipelines, canonical truth stores — typically bolt together a Neo4j instance, a Qdrant or Pinecone vector store, and an embeddings service. NornicDB replaces that stack with a single deployment. Hybrid retrieval (vector search followed immediately by graph hop expansion) runs inside one execution path, eliminating cross-service round trips and the consistency hazards that come with keeping two stores in sync.
NornicDB ships hardware-accelerated inference paths for Apple Silicon (Metal), NVIDIA GPUs (CUDA), and Vulkan-capable hosts, alongside a CPU-only build. It includes a built-in MCP server so LLM agents can store, recall, and discover knowledge directly via standard Model Context Protocol tooling — no extra infrastructure layer required. Knowledge decay policies let the system automatically deprioritize stale nodes over time using configurable decay profiles, which makes it particularly well-suited for long-lived agent memory systems.
Architecture NornicDB follows a layered modular architecture built around a central storage engine that services multiple protocol adapters. At its core sits an AsyncEngine that provides write-behind caching over a persistent Badger v4 key-value store, with separate in-memory indexes for nodes, edges, and label-keyed lookups that allow graph traversal to resolve from cache before hitting disk. The Cypher execution layer is cleanly separated from storage, routing queries through either a custom hot-path streaming executor optimized for common traversal shapes or an ANTLR-generated parser for full correctness coverage — and this mode is switchable at runtime without restarting the server. The nornicdb package acts as the domain facade, composing storage, search, embedding, inference, knowledge policy, temporal tracking, and replication as distinct subsystems wired together at open time. Protocol adapters for Bolt, REST, GraphQL, Qdrant gRPC, and the native Nornic gRPC surface share this single composed database instance, meaning all protocol paths share cache coherence, MVCC version state, and policy evaluation without duplication.
Tech Stack NornicDB is written in Go 1.26 and compiled to a single self-contained binary. Persistent storage uses Badger v4 as the underlying key-value engine, accessed directly without an ORM layer. Vector indexing uses a custom HNSW implementation with hardware-specific SIMD acceleration paths — leveraging Metal on Apple Silicon, CUDA via CGo bindings in the lib/cuda directory, and Vulkan on compatible hosts, with a pure Go CPU fallback. The Cypher query layer includes an ANTLR4-generated Go parser alongside a hand-written fast-path parser. GraphQL is served via gqlgen. Observability runs on OpenTelemetry with Prometheus metrics export. Embedding inference can use bundled model files (bge-m3) loaded via a llama.cpp-style CGo bridge in lib/llama, or delegate to an external OpenAI-compatible API. The MCP server speaks JSON-RPC over HTTP. Multi-platform Docker images are the primary distribution mechanism.
Code Quality The test suite is extensive, with over a thousand test files spread across the main server package and every major subsystem — including dedicated benchmark suites for query shapes, HNSW construction, and hybrid retrieval latency. Tests follow Go standard testing conventions with testify for assertions. The codebase exhibits consistent error typing: a shared errors package defines normalized error values like ErrConflict, ErrNotFound, and ErrQueryEmbeddingDimensionMismatch rather than returning raw strings. Package documentation is thorough, with many packages including ELI12-style explanations alongside formal API docs, and a substantial docs directory covering architecture decisions, performance methodology, and migration guides. A CI coverage badge via Coveralls is present, and Go Report Card integration is wired up. The CONTRIBUTING.md and SECURITY.md files round out the project health indicators.
What Makes It Unique What genuinely differentiates NornicDB from both Neo4j and standalone vector databases is the unification of three query semantics — graph topology, vector proximity, and temporal version state — in a single engine with no cross-service coordination. Most graph-RAG architectures require managing consistency across a graph store, a vector store, and an embeddings microservice; NornicDB collapses all three into one execution path where a hybrid retrieval query (vector nearest-neighbor followed by relationship expansion) is internally consistent by construction. The knowledge decay system is also novel in production database contexts: rather than requiring application code to manage memory staleness, NornicDB applies Kalman-filtered access pattern tracking and declarative decay profiles at the storage layer, so agent memory systems get automatic relevance management without bespoke application logic. The BM25-seeded HNSW construction strategy — using lexical ordering to reduce traversal waste during index build — is an implementation-level optimization that achieves measurable build time reductions without compromising recall quality.
NornicDB is released under the MIT License, which is one of the most permissive open-source licenses available. MIT grants you the right to use, copy, modify, merge, publish, distribute, sublicense, and sell copies of the software — commercially or otherwise — with no copyleft obligations. You are not required to open-source your own application code when you embed or build on top of NornicDB. The only requirement is preserving the copyright notice in distributions.
Running NornicDB yourself means taking on the full operational stack. The server is distributed as Docker images (tagged by architecture and GPU backend) or as native macOS binaries, which simplifies initial deployment considerably. However, you are responsible for persistent volume management, backup schedules, MVCC retention floor configuration, TLS certificate rotation, and monitoring integration via the built-in Prometheus and OpenTelemetry exporters. The database does not bundle a managed replication or HA layer in the open-source build; running a highly available multi-node topology requires you to design and operate that topology yourself using the replication primitives exposed in the codebase.
NornicDB does not currently offer a hosted or commercial cloud tier based on publicly available information, so there is no managed alternative to compare against. What that means in practice is that you gain full data sovereignty and avoid vendor lock-in, but you also own upgrades, data migrations between versions, and capacity planning. The project maintains an active release cadence — over 50 releases since its December 2025 launch — which is positive for feature availability but means staying current requires attention. Community support is available via Discord; there are no commercially backed SLAs.
No Code Platforms · AI Development · Developer Tools
Visual LLM workflow platform with RAG pipelines, agent capabilities, and model management for building production AI applications.
Developer Tools · Databases · Search
The open-source Postgres development platform that replaces Firebase with authentication, real-time APIs, edge functions, storage, and vector embeddings — all built on PostgreSQL.
AI Code Assistants · AI Development
Orchestrate an army of AI coding agents—Claude Code, Codex, Gemini CLI, and more—running simultaneously in isolated git worktrees from a single Electron desktop app.