Why We Built Our Own Graph Database

Why a graph database at all

EdgeX11's hermetic organizational memory isn't a pile of documents. It's a living graph: code connected to the decisions behind it, deployments connected to what broke and how it was fixed, people connected to the systems they know. The value is in the relationships, and relationships are exactly what relational tables make expensive to traverse.

So a graph database was never optional for us. When an AI employee reasons about a change, it walks that graph — hop by hop, the way a tenured engineer would — instead of running a dozen joins. The database isn't infrastructure sitting beneath the product. For us, it is the product.

Why not just use Neo4j

To be clear: Neo4j is a superb database, and we ran on it happily for a long time. This isn't a teardown. It's a story about fit.

As the memory layer became the core of everything, a few things started to rub. Neo4j runs on the JVM, which means a heap to tune and a memory footprint that felt heavy for what we were doing. It wants to be operated — another moving part to run, watch, and pay for. And the licensing model kept forcing decisions we didn't want to keep making as a small team shipping a multi-tenant product.

What we actually wanted was almost embarrassingly simple: a graph database we could ship as a single binary, embed when we needed to, run per-tenant without ceremony, and otherwise forget about. Something that did graph queries and vector search in one place, because our workload is retrieval-augmented reasoning over a graph.

We didn't want a database to operate. We wanted a database to forget about.

What Axon is

Axon is a property-graph database written in pure Go. The whole thing is one static binary of about 19 MB — the same size as a Docker image you can docker run and be querying in under a minute. No JVM, no cluster to stand up.

• Cypher and Bolt. It speaks the query language you already know — MATCH, MERGE, CREATE, aggregation, WITH pipelines, parameters, CALL procedures — and the Bolt wire protocol, so the official Neo4j drivers connect to it unchanged.
• Vector search, built in. HNSW indexes (cosine and euclidean) over node properties, live-synced on write. One query can traverse relationships and rank by embedding similarity — which is the whole game for GraphRAG, without gluing a separate vector database alongside.
• 17+ graph algorithms. PageRank, community detection (Louvain, label propagation), centrality, connected components, shortest path, and more, as callable procedures.
• Ontology & inference. Classes, cycle-checked subclass hierarchies, and label-subsumption inference at query time.
• Multi-tenant by design. Per-database isolated storage engines — the same tenant isolation the EdgeX11 security model depends on.
• Built to run anywhere. Static binary, small Docker image, an embeddable Go library, an HTTP JSON API, and an interactive REPL. BadgerDB (an LSM engine) with MVCC transactions underneath.

The benchmarks — including where we lose

A benchmark you can only win is marketing, not information. Here's the full picture from our latest harness runs — updated August 2026 — so you can decide whether Axon fits your workload rather than ours. Two harnesses, two questions: how does each engine's query planner handle real query shapes, and how fast is each engine end-to-end through the same wire protocol and driver?

Sixteen query shapes on a real production graph

Setup: sixteen query shapes against a real production graph — 2,668 nodes / 4,736 relationships, every node carrying a 768-dimension embedding — exported from a live Neo4j and loaded into Axon immediately before the run, so both engines hold identical data. Both are measured in the same run through the same client (cmd/h2h-bench), so the ratio is the number that survives a shared, noisy machine; best of 21. All sixteen queries return identical results on both engines.

Scroll the table sideways on a narrow screen.

Read it straight: Neo4j's planner leads twelve of the sixteen shapes. But every one of those wins is now under 2× — in our earlier 10k-node run the same class of queries went to Neo4j by 2–3.6×, so the planner gap is closing release by release. And where Axon's storage layout pays off, it pays off big: counting shapes go to Axon by 2–3×, and the label-anchored two-hop count — the shape our memory queries hit constantly — by 45×.

Head-to-head over Bolt, same driver, same Cypher

Setup: identical workloads through the official Neo4j Go driver against both engines' Bolt listeners — same protocol, same client, same Cypher (cmd/bolt-bench; fresh Docker containers, Apple M2 8 GB, otherwise idle; Neo4j 2026.06.0 community, 2 GB heap, JIT-warmed; 400k-node dataset, indexed).

Scroll the table sideways on a narrow screen.

The shape is clear and we're not going to spin it. Through the same driver and protocol, Axon is decisively faster where our workload lives: writes under concurrency, and indexed reads. Query shape by query shape, Neo4j's mature, cost-based planner still wins most rounds — by margins that have shrunk from multiples to fractions.

That's not a mystery; it's a roadmap. Those exact shapes are what our current query-engine work targets. Which is a good moment to be honest about what Axon is and isn't yet.

Where Axon is on the road

Axon is young and we'd rather say so than imply otherwise. The single-node core is shipped and hardened; the work now is making the query engine as smart as the storage engine is fast.

• Shipped — the core: graph storage, a Cypher lexer/parser/executor, a Bolt protocol server the official Neo4j drivers connect to unchanged, MVCC transactions, the algorithm library, HNSW vector search, ontology inference, multi-tenancy, the HTTP API and shell, cross-platform binaries and CI.
• In progress — query-engine maturity: range indexes and constraints, a cardinality-driven planner, EXPLAIN/PROFILE, cost-based join ordering, and parallel scans are in. Composite indexes, parallel aggregation, streaming results and full-text search are next — which is precisely where the remaining sub-2× benchmark gaps close.
• Next — ecosystem and AI: official Go/Python/JavaScript clients, a GraphQL API, and an MCP server so LLM agents can query the graph directly.
• Later — a deeper semantic layer, enterprise operations (RBAC, SSO, audit, encryption at rest), and distributed clustering.

The roadmap moves faster than a blog post can, so treat the list above as a snapshot rather than a commitment.

Why the engine stays in-house

When we first wrote about Axon we published it under an open-source licence, and we said the database would stay that way. Four days later we changed our minds. That is a short half-life for a commitment, so it deserves an explanation rather than a quiet edit.

What changed is what we're building on top of it. The next thing Axon needs to do is enforce access control at the level of individual nodes and relationships — so a fact created by one team is not merely filtered out of another team's results, but never matched in the first place — and to make deletion provable: remove a source, and every fact, edge, summary and embedding derived from it goes with it, with a certificate to show for it.

Both of those are only possible inside the engine. Anyone building a memory layer on a database they didn't write can filter after the query returns, and can delete the rows they know about. They cannot enforce during the match, and they cannot guarantee that nothing survives in a vector index they don't control. That capability is the product, not a feature of it.

So Axon is proprietary from v0.8 onward. The preview releases we published under the old licence stay under it — we're not pretending otherwise or trying to claw them back. If this reads as a reversal, it is one, and we would rather say so plainly than quietly rewrite the earlier post and hope nobody kept a copy.