In-Memory vs Disk-Backed Graph Database for Agent Memory

Most teams pick a graph database for agent memory the same way they pick a laptop: by what runs fast today. The demo has 40,000 memories, the whole graph fits in RAM, queries come back in single-digit milliseconds, and nobody asks what the box looks like in eight months.

That is the wrong test. Agent memory is append-heavy. Every conversation, tool call, and extracted fact adds nodes, edges, and an embedding, and almost nothing gets deleted. An in-memory graph database is fast. Nobody disputes that. What matters is whether your working set stops growing before it hits your RAM ceiling.

This post is a decision by arithmetic. We size the working set in bytes, project growth, then check two failure points: the RAM ceiling and restart time. In-memory engines like Memgraph win when the working set is sizable and bounded. HelixDB wins when memory keeps growing, because it runs across memory, disk, and object storage. Pick with numbers, not vibes.

Who should pick which: a short verdict up front

Pick an in-memory graph database like Memgraph if your hot working set is bounded, fits comfortably in RAM with headroom, and every millisecond of traversal latency is worth paying for in hardware. A fraud-detection graph with a fixed entity count, or a recommendation graph that gets rebuilt nightly, fits that profile.

Pick HelixDB if your graph is an append-only log of what agents have seen and done. Its vector implementation runs across memory, disk, and object storage, and you choose the run mode: embedded in memory or on disk, a self-hosted Docker server (in-memory, on-disk, or S3-compatible object storage), or HelixDB Cloud. Same engine, same SDKs, same endpoint in each mode.

Neo4j vector indexes are Lucene-based and use the operating system's filesystem cache rather than running as an entirely in-memory vector index, with performance benefiting from keeping index files in that cache. We covered that sizing problem in Neo4j Vector Index Memory: Sizing Agent Memory Accurately.

The rest of this post shows how to tell which side of the line you are on. If you only read one section, read the next one and do the arithmetic with your own numbers.

How to size a working set: nodes, edges, properties and vector bytes

Start with vectors, because they dominate. HelixDB normalises vector values to float32, so each dimension costs 4 bytes. A 1536-dimension embedding is 6,144 bytes raw. A 768-dimension one is 3,072 bytes. Multiply by the number of embedded nodes and edges.

Then add index overhead. An HNSW graph stores neighbour lists per vector. A common rule of thumb is to budget 20 to 50 percent on top of raw vector bytes for links at typical M values, but the exact figure depends on M, layer distribution, and the engine. Treat it as a planning range, then measure on your own data.

A worked example. One million memories, 1536 dimensions, float32:

• Raw vectors: 1,000,000 x 6,144 B = about 6.1 GB

• HNSW overhead at 30 percent: about 1.8 GB

• Vector total: about 7.9 GB

Now the graph itself. Say each memory node carries 500 bytes of properties (text snippet, timestamp, source, entity tags) and averages four edges at roughly 100 bytes each. That is about 900 bytes a node, or 0.9 GB per million. Add engine overhead for ids, indexes, and a BM25 text index if you use one, and call it 1.5 GB.

Total for one million memories: roughly 9.5 GB. Ten million is 95 GB. At 1536 dimensions, a million memories costs about as much RAM as a decent laptop has free.

Do this arithmetic with your embedding model's real dimension count. If you later switch models, the numbers change. See Re-embedding Agent Memory After You Change Models.

Why agent memory only grows (and what that does to your RAM budget)

Caches evict. Agent memory does not. A support agent that handles 2,000 conversations a day, extracting ten memories per conversation, adds 20,000 nodes a day. That is 7.3 million a year from a single agent. Run a fleet of agents sharing one graph, as in Shared Memory for Multi-Agent Systems: One Graph to Query, and the slope gets steeper.

Project it. Using the 9.5 GB per million figure from above:

Month	Memories	Approx. RAM if all resident
1	0.6M	5.7 GB
6	3.7M	35 GB
12	7.3M	69 GB
24	14.6M	139 GB

The jump from month 6 to month 24 is the whole argument. At month 6 you are on a standard instance. At month 24 you are shopping for memory-optimised hardware, and that is for one agent's traffic.

Most of that data is cold. Last quarter's conversation about a resolved ticket rarely gets recalled. But an engine that keeps the entire graph and index resident pays RAM prices for every byte, hot or not. Agent memory has a classic skewed access pattern, with recent and frequently linked nodes taking most reads. An architecture that tiers by temperature matches that pattern. One that does not turns your oldest memories into your most expensive line item.

Set your own projection before you choose. If the line flattens below your RAM ceiling, in-memory is fine. If it does not, you are choosing a migration date.

What happens at the RAM ceiling and on restart: snapshots, WAL and recovery time

Two failure points matter, and teams usually only plan for the first.

The RAM ceiling. In an all-in-memory engine, hitting the limit is a hard event. Memgraph, for example, can be configured with a memory limit, after which queries that need more memory fail. Your options are then vertical scaling, deleting data, or moving to a bigger box. None of those are gradual. You find out at 3am when the ingest worker starts erroring.

Restart time. An in-memory engine keeps durability through a write-ahead log plus periodic snapshots. After a crash or a deploy, it loads the latest snapshot into RAM and replays the WAL on top. Recovery time scales with the data size: a bigger graph means a longer snapshot read, a longer WAL replay, and for vector indexes, often a rebuild or reload of the HNSW structure. Plan for it empirically. Take a snapshot of your real graph, time a cold restart on production-class hardware, and write the number in your runbook. If that number is ten minutes, your agents are without memory for ten minutes on every restart, unless you run a replica and fail over.

The things to measure before you commit:

• Snapshot size and snapshot load time on your actual hardware

• WAL replay time for a realistic write backlog

• Time until the vector index is queryable after restart

• Peak RAM during recovery, which can exceed steady-state RAM

HelixDB Cloud persists nodes, edges, properties, and indexes durably in object storage, with a gateway routing traffic, a single writer serializing mutations, and reader nodes that scale horizontally behind tiered caching. State lives in durable storage rather than only in a process's heap, so a restart is a cache warm-up question rather than a load-everything-first question. For the architecture in more detail, see Graph Database on Object Storage: How Agent Memory Scales.

Side-by-side: Memgraph, Neo4j and HelixDB across memory, durability, scaling and ops

Here is the comparison on the criteria that matter for an append-heavy agent memory workload. The Memgraph and Neo4j columns describe general architecture. Verify specifics against their current docs for your version.

Criterion	Memgraph	Neo4j	HelixDB
Where data lives at query time	In RAM	Graph store on disk with page cache; vector index in memory	Memory, disk, or object storage, by run mode
Vector index storage	In memory	Entirely in memory	Runs across memory, disk, and object storage
Durability model	WAL plus snapshots	Transaction log plus store files	HelixDB Cloud persists to object storage; self-hosted runs in memory, on disk, or against S3-compatible storage
Behaviour at RAM limit	Memory limit reached, queries needing more memory fail	Vector index growth competes for heap and page cache	Tiering means the working set can exceed RAM
Restart story	Load snapshot, replay WAL	Reopen store, rebuild or reload indexes	Durable state in storage; caches warm back up
Read scaling	Replicas	Read replicas or clustering	Cloud reader nodes auto-scale horizontally behind a single writer
Ops burden	Size RAM, tune snapshots	Size heap, page cache, and index	Choose a run mode; managed option in HelixDB Cloud

Two things to notice. First, the in-memory advantage is real in the first row: if everything is resident, you skip disk entirely on the read path. Second, the rows that favour HelixDB are all about growth: what happens when the data outruns the machine.

The general shape of this tradeoff is covered in Memgraph Alternatives for Agent Memory: When RAM Becomes the Limit. If you want to test claims like these yourself rather than trust a table, How to Benchmark a Graph Database for AI Retrieval Accurately walks through a method.

Where in-memory wins, and where HelixDB's memory, disk and object-storage tiering wins

The in-memory case is a strong one, so here it is straight.

In-memory wins on tail latency when the working set fits. If every node, edge, and vector is already in RAM, a multi-hop traversal never waits on a page fault. For latency budgets measured in single-digit milliseconds, with a graph that stays under, say, 40 percent of available RAM, an all-in-RAM engine like Memgraph is a clean fit. It also wins when the workload is read-heavy over a stable dataset: you size once and stop thinking about it. If your agent memory is capped by design, for example a rolling 90-day window with hard deletes, you have a bounded working set and the arithmetic favours RAM.

HelixDB wins when the line on the growth chart does not flatten. The tiering across memory, disk, and object storage means the hot set lives in memory while colder data sits on cheaper tiers, so your cost follows the data's access pattern instead of its total size. Storage on HelixDB Cloud plans is listed as unlimited, with usage priced in reads and writes. The entry Idea plan is $5 a month for 200K reads and 100K writes (check helix-db.com/pricing.md before quoting numbers, since pricing changes).

It also wins on retrieval design. Vector pre-filtering lets vector search run over a graph-filtered candidate set instead of the whole index, so a query like "memories related to this customer" does not rank across every embedding you have ever stored. Per-query work stays tied to the relevant neighbourhood as the total graph grows. Efficient time-range indexing helps the same way for recency queries. See How to Query Agent Memory by Time Range Without a Full Scan. Temporal modelling itself is something you build, but range scans over time are fast.

In HelixDB's own benchmarks, graph traversals run up to 1000x faster than Neo4j, and vector performance is on par with Pinecone and Qdrant. Those are vendor benchmarks, so rerun them on your data before you rely on them.

Verdict: choose in-memory if..., choose HelixDB if...

Choose an in-memory graph database if:

• Your projected working set stays below roughly half your RAM ceiling for the life of the product

• You have a retention policy that actually deletes data, so growth is bounded

• Your cold-restart time, measured on real hardware, fits inside your availability target (or you run replicas to cover it)

• Single-digit-millisecond traversal latency is a hard requirement and you will pay for memory to get it

Choose HelixDB if:

• Memory is append-only and the arithmetic above puts you past your RAM ceiling within a year or two

• You want vectors, graph traversal, and BM25 full-text in one engine rather than a vector database synced to a graph database

• You want to start embedded in memory or on disk, then move to a self-hosted server or HelixDB Cloud without changing engine or SDKs

• You want restart and recovery to be a cache-warming question instead of a load-the-whole-graph question

If you are undecided, the cheap test is to load a realistic slice of your agent memory into both and watch two numbers: p99 query latency and cold-start time. Do not skip the second. The first number is where in-memory shines. The second is where it bites.

The tradeoff is real but lopsided for this workload. A fixed-size dataset rewards RAM. A dataset that only grows rewards tiering.

Conclusion

Do the arithmetic before you pick. Take your embedding dimension, multiply by 4 bytes, add HNSW overhead, add graph properties, then project twelve months of appends. If the number crosses your RAM ceiling, you are picking a migration date, not a database.

If agent memory is what you are building, try HelixDB on your own data. Star the repo at github.com/HelixDB/helix-db, and join the Discord to show us what your growth curve looks like.