Why Retrofitting Real-Time Graph Workloads Gets Expensive

By Sabika Tasneem

9 min readSeptember 24, 2026

Most graph database evaluations begin with a feature matrix. However, features show what a database can do in isolation, whereas architecture determines what happens when it must do everything at once.

A fraud platform may ingest transactions while traversing account relationships to score risk. An infrastructure system may update dependencies while calculating exposure. An AI agent may write memory, retrieve context, and choose its next action within the same loop.

These workloads do not separate transactions, traversal, and analytics into convenient windows. They run them concurrently against a graph that never stops changing. For teams evaluating a graph database, the practical question is whether ingestion, traversal, and decision-making can operate on the same current graph.

You can add a cache, faster storage, a stream processor, or a separate analytical service. Each can improve one part of the system, but none removes the underlying storage, synchronization, or freshness boundaries.

For real-time graph workloads, architecture creates three constraints:

Latency has a floor, and it's set by where the data lives.
Throughput has a ceiling, and it's set by how conflicts are resolved.
Freshness has a boundary, set by whether analytics run on the live graph or a separate copy.

That is why real-time performance must be designed into the database rather than added later.

What Real-Time Means for Graph Workloads

“Real time” does not simply mean that one query runs quickly in a demonstration. It means the database can continue accepting new data while queries read and analyze the graph.

For example, a fraud detection system may receive a new transaction, update relationships between accounts, and check those relationships for suspicious patterns at the same time. The system must complete all of these tasks within the required decision-making window.

A real-time graph workload combines four conditions:

Continuous data ingestion
Concurrent reads and writes
Traversal or analytics over current data
Analytics on changing graph data without exporting it first

These capabilities can be provided through database-managed streaming, transactional isolation, an appropriate storage model, and algorithms that operate on the operational graph.

Actual latency still depends on the graph, query, hardware, and workload. The relevant test is whether the database maintains the required latency and freshness under the expected workload.

The Storage Path Sets the Latency Floor

Graph traversals amplify storage decisions. A key-value lookup may touch one record. A multi-hop graph query can follow thousands of relationships, with each expansion depending on the previous one. Small delays compound across the traversal.

In a disk-based engine, memory typically acts as a cache for data whose durable representation remains on disk. Neo4j, for example, explains that its page cache holds graph data stored on disk to reduce disk access.

This architecture has clear advantages. It supports graphs larger than memory and provides a familiar durability model. When the relevant data is cached, it can perform well.

The trade-off is that cache state becomes part of performance. Teams must size the cache, manage warmup after restarts or failovers, monitor page faults, and account for the path taken when required data is absent from memory.

A cache speeds up access when data is already in memory, but uncached data must still be retrieved from disk.

An in-memory-first graph engine begins with a different assumption: the current graph should live and be traversed in RAM. In Memgraph’s default IN_MEMORY_TRANSACTIONAL mode, the graph is stored in memory, while write-ahead logs and periodic snapshots are written to disk for durability and recovery. Its storage modes support other trade-offs where analytical throughput or disk capacity takes priority.

Memory still remains finite. However, it changes the capacity problem. Instead of estimating which parts of the graph will remain cached, teams must size the in-memory dataset and its expected growth against available memory. Teams can keep less frequently accessed historical data in lower-cost storage while retaining the active topology in memory.

In-memory query path vs. disk-backed query path comparison.png

The distinction is not “RAM good, disk bad.” It is about choosing the query path that matches the workload. If the active topology must be traversed repeatedly within a strict latency budget, keeping that topology close to the execution path becomes an architectural decision, not merely a tuning choice.

Read more: Compare Memgraph and Neo4j

The Concurrency Model Governs Parallel Performance

Keeping the graph in memory is not enough to support real-time graph workloads if independent updates still have to wait for one another.

A fraud graph may receive payment events, device relationships, and identity signals from several producers. Multiple AI agents may append interactions and update state at the same time. Meanwhile, queries are traversing those relationships to make decisions.

If independent writes queue behind a single writer or contend on broad locks, storage speed will not remove the bottleneck.

The key question is not whether the database supports transactions, but how those transactions interact:

Can unrelated writes proceed concurrently?
How narrowly does the engine lock graph elements?
What snapshot do readers see during updates?
What happens when writers touch the same data?
Do high-degree nodes become ingestion hot spots?

Memgraph combines multi-version concurrency control with fine-grained locking. Readers receive a consistent snapshot while independent writes can update different nodes and relationships concurrently. Writes affecting the same graph elements may still conflict and require a retry. For append- and update-heavy workloads without deletes, ACID requirements, replication, or high availability, switching to IN_MEMORY_ANALYTICAL mode can avoid these conflicts and increase write throughput.

This model can suit continuously changing graphs because contention is more closely tied to the data being modified. A read-heavy graph that receives only occasional batch updates may not need the same concurrency model. A live operational graph should not treat it as an afterthought.

The Execution Model Creates a Freshness Boundary

Another architectural choice is whether transactional queries and analytical workloads operate on the same graph state.

Separating them can be useful. The operational database handles writes, while a projection, snapshot, or dedicated analytical service runs algorithms. Teams can scale the two environments independently and protect transaction performance from expensive analytical work.

Amazon Neptune follows this model. Neptune Analytics complements Neptune Database and can load graph data from Neptune Database, snapshots, or Amazon S3. This allows independent scaling, but it also introduces a synchronization boundary between the graph receiving writes and the graph used for analysis.

Teams must decide how often the analytical graph is updated, how stale results may become, how failed synchronization is detected, and which graph state produced a result. A managed service does not remove those synchronization and freshness responsibilities.

For workloads where delayed results are acceptable, this separation may be the right design. A fraud score may need to reflect a transaction committed moments earlier, while an infrastructure-dependency analysis may tolerate a much older snapshot.

Running analytics against the live operational graph removes the need to coordinate multiple graph states. Memgraph’s dynamic graph algorithms can also update affected results as the graph changes instead of repeatedly recalculating everything from scratch.

Freshness is therefore not only a data-pipeline setting. It is a consequence of where computation runs.

Retrofitting Creates a Coordination Tax

Architectural limitations rarely remain contained inside the database. They move into the surrounding application.

A team may add a cache to improve latency, a stream processor for ingestion, an analytical projection for algorithms, and a vector database for semantic retrieval. Each component can solve a legitimate problem. Together, they introduce new responsibilities:

Copying and synchronizing data
Coordinating retries and timeouts
Maintaining schemas, indexes, and embeddings
Enforcing access control across services
Monitoring additional failure domains
Tracing which data produced a result

This coordination tax appears as additional infrastructure, synchronization work, failure modes, and uncertainty about which data produced a result. It is paid in infrastructure, engineering effort, and uncertainty about freshness.

GraphRAG makes that tax especially visible. A single request may involve vector or text search, graph traversal, filtering, ranking, and prompt construction. When these operations run across separate systems, retrieval becomes a distributed workflow.

Memgraph’s Atomic GraphRAG approach can compose those operations in a single Cypher query against the live graph. The retrieval policy can be inspected, tested, versioned, and optimized in one place.

Atomic GraphRAG Pipelines.png

The benefit is not only a simpler architecture diagram. Fewer system boundaries also make it easier to trace which data produced a result.

10x Code Reduction with Atomic GraphRAG.png

Choose Architecture Before Features

Disk-based graph databases remain suitable for large graphs and workloads where capacity outweighs strict latency predictability. Separate analytical systems make sense when independent scaling or managed operations matter more than immediate freshness. No architecture is optimal for every workload.

The mistake is choosing an architecture for one workload and assuming features can later transform it into another. Before comparing feature lists, ask four questions:

Where does the active topology live?
Can independent writes progress concurrently?
Do analytics run against the current graph or a copy?
How many systems stand between an event and a decision?

For real-time operational graphs, the answers must align. The current graph needs a short query path. The concurrency model must support continuous mutation. Analytics must reflect the required graph state. Each additional boundary must justify the latency and coordination it introduces.

Memgraph is designed for this operating model, keeping transactions, streaming updates, traversal, analytics, and AI retrieval close to the live graph. The relevant question is whether that model matches your workload’s latency, freshness, and concurrency requirements.

You can optimize around an architecture, but removing its fundamental boundaries usually requires redesigning the systems beneath it. That is why the underlying architecture places a limit on how far later optimizations can take you.

If your workload requires frequent updates and decisions against the current graph, start by testing Memgraph with a representative workload or talk with a graph engineer about your latency, concurrency, freshness, and capacity requirements.