HydraDB vs Memgraph
HydraDB vs Memgraph: Graph Context For AI Agents
Memgraph is optimized to query the graph you have now. HydraDB is designed to preserve how that graph changed and reconstruct the state an agent should reason over.
Dimension
HydraDB
Memgraph
Old facts
Keeps old versions, so past state can still be queried
Usually keeps the current graph unless history is modeled separately
Time
Tracks when relationships were added and when they were valid
Time can be stored, but history rules are defined by the application
State history
Can rebuild what the graph looked like at an earlier point
Requires custom modeling and queries to rebuild past state
Agent context
Gives agents context based on the right state at the right time
Can build GraphRAG context, but temporal state must be handled separately
Storage
Uses object storage as the durable source of truth
Mainly runs as an in-memory graph with WAL and snapshots for durability
Scaling
Query and indexing compute can scale separately
Querying and retrieval run inside the graph database engine
Best fit
Agents that need to reason over changing relationships and state
Fast real-time graph and GraphRAG workloads
Supernode Reads & Writes, Measured
We benchmarked HydraDB against Memgraph on supernode workloads — entities with 100 to 10,000 relationships, a shape common in agent-memory graphs — across read latency, read throughput, and durable writes. Every result below, including the ones Memgraph wins, is published as measured.
For each degree D, the fixture contains D independent chains rooted at vertex 1, each 20 edges deep — the largest fixture has 200,000 relationships. Every fixed-hop read must return exactly D destinations.
MATCH (u:BenchNode {id: 1})-[:USER_FOLLOWS_USER*H..H]->(v)
RETURN count(*) AS totalMATCH (u {id: 1})-[:USER_FOLLOWS_USER*H..H]->(v)
RETURN count(*) AS totalMERGE (a:BenchNode {id: $src})
-[:USER_FOLLOWS_USER]->
(b:BenchNode {id: $dst})- Degrees tested: 100, 1,000, 5,000, and 10,000 relationships per node.
- Read depths: 1, 3, 5, 10, and 20 hops.
- Serial latency: 10 warmups followed by 100 measured requests per cell.
- Concurrent throughput: 8 Bolt sessions, 25 requests each — 200 operations per cell.
- Writes: 10 warmups, 100 serial requests, then 200 operations at concurrency 8 per degree.
- Reads are warm-cache, steady-state measurements.
- HydraDB uses its local object-store backend and the GraphBLAS kernel.
- Memgraph ran with 6 CPUs and an 8 GiB limit, WAL flushed every transaction (not Memgraph's 100,000-transaction default), so the write comparison is durability-fair.
- Both engines ran sequentially on the same, otherwise idle host.
All 20 read cells returned the expected count and every measured write succeeded — no query timeouts or correctness failures.
Exact-match query — identical Cypher on both engines
Both engines run the identical labelled-ID query. Memgraph has an index on :BenchNode(id); that labelled anchor currently misses HydraDB's direct structural-ID access path.
| Relationships / node | 1 hop | 3 hops | 5 hops | 10 hops | 20 hops |
|---|---|---|---|---|---|
| 100 | 0.97 0.46 | 1.04 0.52 | 1.05 0.55 | 1.07 0.62 | 1.27 0.78 |
| 1,000 | 5.34 0.53 | 5.89 0.92 | 5.80 1.40 | 6.49 2.26 | 6.71 4.16 |
| 5,000 | 64.64 0.76 | 70.26 3.24 | 69.49 6.37 | 70.49 10.21 | 68.75 17.28 |
| 10,000 | 135.82 1.14 | 137.12 7.83 | 137.71 11.63 | 139.88 19.97 | 140.96 33.59 |
| Relationships / node | 1 hop | 3 hops | 5 hops | 10 hops | 20 hops |
|---|---|---|---|---|---|
| 100 | 4,813 7,191 | 4,604 8,969 | 4,362 8,232 | 4,153 7,462 | 3,460 5,928 |
| 1,000 | 791 8,913 | 682 4,535 | 746 3,551 | 676 1,925 | 615 991 |
| 5,000 | 58 5,074 | 52 1,559 | 56 737 | 53 437 | 58 262 |
| 10,000 | 29 2,428 | 29 656 | 28 393 | 27 239 | 24 128 |
At degree 10,000 and 1 hop, the exact query takes 135.82ms p50 versus 0.77ms for the native-ID form. Lowering labelled ID equality to the same direct vertex-ID lookup, while retaining label validation, is the next optimization target.
Native-path query — each engine's intended fast path
HydraDB uses its native structural vertex ID instead of a labelled property match. Memgraph uses the same indexed lookup as above, since that was already its intended point-lookup path — this is each engine running its own best case.
| Relationships / node | 1 hop | 3 hops | 5 hops | 10 hops | 20 hops |
|---|---|---|---|---|---|
| 100 | 0.39 0.46 | 0.40 0.52 | 0.41 0.55 | 0.45 0.62 | 0.51 0.78 |
| 1,000 | 0.40 0.53 | 0.68 0.92 | 0.69 1.40 | 0.92 2.26 | 1.45 4.16 |
| 5,000 | 0.51 0.76 | 1.03 3.24 | 1.54 6.37 | 2.72 10.21 | 5.09 17.28 |
| 10,000 | 0.77 1.14 | 1.74 7.83 | 2.85 11.63 | 4.63 19.97 | 8.34 33.59 |
| Relationships / node | 1 hop | 3 hops | 5 hops | 10 hops | 20 hops |
|---|---|---|---|---|---|
| 100 | 15,764 7,191 | 11,713 8,969 | 13,393 8,232 | 12,585 7,462 | 10,111 5,928 |
| 1,000 | 13,643 8,913 | 8,870 4,535 | 7,595 3,551 | 5,729 1,925 | 2,526 991 |
| 5,000 | 9,341 5,074 | 3,345 1,559 | 1,892 737 | 822 437 | 448 262 |
| 10,000 | 3,663 2,428 | 810 656 | 498 393 | 272 239 | 133 128 |
HydraDB wins p50 in all 20 native-path cells. At degree 10,000 and 20 hops, HydraDB is 4.03x lower at p50 and 3.64x lower at p99; concurrent throughput converges to 132.69 QPS versus Memgraph's 128.26 as both saturate the six available CPUs.
Durable supernode writes
Each write adds a new destination to the existing supernode. Degree is the root's relationship count before the measured additions.
| Relationships / node | p50 (lower better) | p95 (lower better) | p99 (lower better) | Throughput (higher better) |
|---|---|---|---|---|
| 100 | 11.32 8.36 | 11.77 18.26 | 12.03 34.22 | 89.97 80.69 |
| 1,000 | 11.34 8.68 | 11.80 37.81 | 11.89 41.56 | 89.89 107.37 |
| 5,000 | 11.34 7.32 | 11.66 12.02 | 11.94 27.60 | 90.22 106.22 |
| 10,000 | 11.34 7.29 | 11.61 38.20 | 11.78 38.54 | 90.04 82.56 |
HydraDB write latency is effectively independent of supernode degree — p50 stays close to 11.3ms from 100 to 10,000 relationships. Memgraph has the faster median, but HydraDB is far more predictable in the tail. With per-transaction fsync, neither engine scales concurrent throughput beyond roughly 80–107 commits/s on this local disk.
// When HydraDB is the better fit //
Choose the system that matches the work
Choose Memgraph when real-time graph processing is the product’s core requirement. Choose HydraDB when the graph is only the starting point—and agents must preserve change, reconcile semantic relevance with relationships, and return grounded context that teams can inspect.
Memory becomes evidence
HydraDB retains the context behind a change, so an agent can explain what was true, what changed, and why its answer is grounded.
Semantic and structural relevance agree
HydraDB ranks graph relationships and vector similarity together, reducing the work required to turn connected data into useful context.
Temporal reasoning is built in
Teams can retrieve a prior state of context when investigating an incident, checking a decision, or correcting an agent’s assumption.
The handoff to the model is deliberate
Instead of returning a raw graph result, HydraDB packages ranked, source-aware context to fit the agent’s available token budget.
Frequently Asked questions
Why would I use HydraDB instead of Memgraph for AI agents?
Both can power graph-based agent memory. HydraDB is designed around large, persistent context graphs, with object storage as the durable source of truth and query/indexing compute scaling independently. That becomes useful as agent memory grows across users, sessions, and applications.
Is HydraDB an in-memory graph database like Memgraph?
No. Memgraph is primarily optimized around an in-memory engine, although it also provides an on-disk transactional mode. HydraDB is object-store-native: the durable graph lives in S3-compatible storage, while RAM and local SSD are disposable performance caches.
What is the biggest architectural difference between HydraDB and Memgraph?
Memgraph focuses on keeping graph processing close to fast local memory or disk. HydraDB separates the durable graph from the compute serving it. Query nodes and indexers can be replaced or scaled independently without moving the underlying graph.
How do HydraDB and Memgraph handle durability differently?
Memgraph persists graph state using snapshots and write-ahead logs, or RocksDB in its on-disk mode. HydraDB writes its canonical graph, WALs, manifests, and traversal indexes into shared object storage, making local memory, SSDs, and compute nodes disposable.
Do HydraDB and Memgraph both support Cypher?
Yes. Memgraph uses Cypher for graph querying, while HydraDB supports a practical OpenCypher subset optimized for its object-store-native execution model. HydraDB also supports Neo4j-compatible Bolt clients and JSON/NDJSON HTTP APIs.
When should I choose HydraDB over Memgraph?
Choose HydraDB when you’re building AI agents, agent memory, or context graphs that need to grow continuously. HydraDB is designed for persistent AI context, with object-store-native durability and independently scalable query and indexing infrastructure, so your graph can grow without being tied to a single machine’s memory or storage.
How should teams evaluate the two systems?
Evaluate the workload first. Test Memgraph for real-time graph operations and graph-backed product features. Test HydraDB for context quality, temporal traceability, hybrid retrieval, and the degree to which an agent can explain the evidence behind its response.
Build agent context that stays correct over time
Move beyond fast graph queries alone. HydraDB keeps evolving historical state, and retrieval logic together so agents receive context they can trust.
HydraDB
