The Single-Writer Bottleneck: Why Write Serialization Limits Real-Time Graph Workloads

By Sabika Tasneem

7 min readSeptember 29, 2026

Your application has 12 workers. Twelve independent events arrive, each producing a write query against the same graph. The database has available CPU capacity. Yet only one write query on that graph can execute at a time. The other 11 writes wait.

The database may accept all 12 requests concurrently, but its concurrency model turns them into one execution lane. Adding more application workers or CPU cores cannot widen that lane.

This is the serialized writer problem. It may not matter for a read-heavy graph that receives occasional updates. It matters when fraud events, security signals, infrastructure changes, or AI agent interactions continuously update the same connected graph.

The architectural question is not simply whether a database supports concurrent clients. It is whether independent write queries can progress concurrently within the graph your application is actively using.

What Does a Serialized Writer Mean?

A serialized writer model allows only one write query or transaction to execute within a defined boundary at a time. Other requests may arrive concurrently, but they must wait and execute sequentially.

The one-writer restriction is not necessarily system-wide. SQLite, for example, explains that it implements serializable transactions by serializing writes so that only one writer operates on a database at a time.

FalkorDB applies this model per graph. Multiple read queries can run in parallel against the same graph, but only one write query can execute at a time. Additional write queries enter a first-in, first-out (FIFO) queue.

When several queries must behave as one transaction, FalkorDB uses Redis MULTI and EXEC. FalkorDB notes that this serializes the enclosed commands and can block operations on other graphs until the transaction finishes.

This model keeps transaction behavior predictable. Writes run in sequence, each writer sees the latest committed state, and readers see a consistent snapshot. The trade-off is lower write throughput for the graph because all writes must share one execution lane.

Limits of a Single Write Lane

A serialized writer creates a straightforward throughput ceiling. The next write cannot begin until the current one finishes. Faster hardware may reduce the execution time of each query, but it cannot make independent writes run in parallel.

As write requests arrive faster or in bursts, the queue grows. One expensive write can delay every request behind it, increasing p95 and p99 latency even when average performance appears acceptable.

Reads can still perform well in this architecture. FalkorDB allows concurrent readers to work from consistent snapshots while a writer is active. The limitation concerns write progress within the same graph.

That distinction matters during evaluation. Strong read performance does not prove that an engine can sustain concurrent mutation.

Why Real-Time Graph Workloads Expose the Limit

A serialized writer may be sufficient when updates are infrequent or arrive in controlled batches. Real-time operational graphs have a different workload shape.

A fraud graph may receive transactions, device associations, login attempts, and identity updates from several producers. A cybersecurity graph may add events while queries search for attack paths. An infrastructure graph may update dependencies while calculating operational exposure.

AI memory creates similar pressure. Multiple agents may append interactions, record tool results, update state, and retrieve context from a shared graph. Agent memory is not written once and queried indefinitely. It changes throughout each reasoning loop.

These updates may affect unrelated parts of the graph. An event concerning one customer does not necessarily conflict with an event concerning another. A serialized writer still places both updates in the same queue when they target the same graph.

Splitting the data across multiple graphs can create additional write lanes. That approach works when the data has natural boundaries and queries do not need to cross them. It becomes harder when the value of the graph comes from traversing connections across customers, devices, agents, services, or events.

Partitioning can increase write parallelism, but it may also move routing and coordination into the application or restrict the traversals the system can perform.

Coarse Locks Can Produce Similar Contention

Not every write-concurrency limitation takes the form of a single writer. Some databases allow several write queries to run at once but lock more data than each query actually changes. As a result, unrelated writes may still block one another or fail because the locked areas overlap.

Amazon Neptune is one example. It uses multi-version concurrency control for read-only queries and record- and index-range locks for writes. Its guidance explains that gap locks can cause false conflicts, blocking a transaction even when it is not changing the same data.

AWS notes that, under high load, approximately 3% to 4% of write queries may fail because of false conflicts and require a retry.

Neptune is not a single-writer architecture, so the source of contention is different. The key question is whether a database blocks only writes that affect the same data or also delays writes that should be independent.

Fine-Grained Concurrency Changes the Trade-Off

An alternative model combines multi-version concurrency control (MVCC) with fine-grained locking.

MVCC maintains multiple versions of changed data so readers can access a consistent snapshot while writes are in progress. Fine-grained locking limits coordination to the graph elements being modified.

Serialized Writer vs. Concurrent Graph Writes.png

Memgraph applies locks at the node and relationship level. Independent transactions updating different parts of the graph can proceed concurrently and use multiple CPU cores. In high-throughput workloads, MVCC, fine-grained locking, and inter-query parallelism allow Memgraph to support concurrent reads and writes.

This model does not eliminate conflicts. Two transactions modifying the same node or relationship may still collide. Under Memgraph’s default snapshot isolation, a transaction commits only if its updates do not conflict with concurrent updates made since its snapshot. Otherwise, the client must retry it.

Simply put, here’s how the three approaches differ:

A serialized writer queues every write targeting the same graph, whether those writes conflict or not.
Fine-grained concurrency allows independent writes to proceed in parallel but requires retries when transactions genuinely collide.
Broader record or range locks allow multiple writers but may block transactions whose physical lock ranges overlap.

The goal is not to eliminate all contention. It is to ensure that unrelated writes do not contend simply because they belong to the same graph.

What to Verify During an Evaluation

A single-client ingestion benchmark cannot reveal a per-graph write-concurrency limit. During a proof of concept, test the following yourself or ask the database vendor to provide the results:

Can multiple clients update different parts of the same graph concurrently?
Does write throughput continue to increase as more concurrent clients are added?
How do p95 and p99 latency and retry rates change under load?
Can reads continue while writes are running, and when do they see newly committed data?

Results will depend on the graph, queries, hardware, durability settings, and client configuration. Any comparison should use equivalent conditions across databases.

Wrapping Up

A single-writer model can work for read-heavy graphs, batch updates, or modest write volumes. It becomes an architectural constraint when multiple clients need to update different parts of the same live graph at once.

Memgraph uses MVCC, fine-grained locking, and snapshot isolation so independent writes can progress concurrently while readers see a consistent graph state. Writes affecting the same data may still conflict and require retries, but unrelated writes are not forced into one per-graph queue. Before choosing a graph database, ask one question:

When several clients update different parts of the same graph, do those writes progress concurrently, or do they take turns?

The answer will tell you more about real-time write capacity than the number of application workers, client connections, or CPU cores.

Ready to evaluate more than one write lane? Test concurrent updates with Memgraph or talk with a graph engineer about your workload’s write-concurrency requirements.