Engine architecture
Designed from the ground up for low-latency agent memory workloads, not retrofitted from a general-purpose vector database.
Most vector databases were built to search millions of documents a handful of times a second. Agent memory is almost the opposite shape: small reads and writes, happening constantly, where a few hundred milliseconds of latency is the difference between an agent feeling instant or feeling sluggish. Every decision below follows from that difference.
HNSW + graph hybrid
Combines fast vector similarity search with structured graph traversal for hybrid retrieval.
- Sub-0.4ms P99 latency
- Capacity depends on workload and hardware
ACID transactional storage
Complete transactional integrity for agent memory writes, with no partial or corrupted state possible.
- WAL journal logging
- Crash-safe recovery
Zero-copy branching
Instant state snapshotting with copy-on-write overhead for parallel agent reasoning trees.
- Instant `claw branch`
- Deterministic replay
Adaptive query planning
Each query is routed to whichever index (vector, graph, or both) actually answers it, instead of always scanning everything.
- Cost-based routing
- No manual index hints
Why sub-millisecond retrieval is possible
Agent memory access patterns look nothing like document search: small payloads, high read frequency, and a strong locality bias toward recent context. Axonio’s index is tuned for that shape of traffic rather than bulk corpus retrieval, trading off some of the raw throughput a document-search engine would optimize for in exchange for consistently low latency on the reads an agent actually makes.
Common questions
What does the 0.38ms P99 figure measure?
Retrieval on the open-source engine in a local, single-node benchmark with a warm cache and small payloads. It is not hosted-service telemetry or an SLA: network hops add to it, so measure against your own data, hardware and network path before setting a production objective.
What happens as memory grows past a few million records?
The HNSW index is built to stay fast at scale by design, but very large single databases benefit from state branching to keep working sets smaller and more relevant rather than one ever-growing store.
Can I run my own benchmarks against it?
Yes. Self-host the runtime from the Database page and measure against your own workload. That’s the most honest number you’ll get, since synthetic benchmarks rarely match real traffic shapes.