Eg-walker — keep the event log, use the CRDT only to merge

"Collaborative Text Editing with Eg-walker: Better, Faster, Smaller", Joseph Gentle and Martin Kleppmann (University of Cambridge), EuroSys 2025 (DOI 10.1145/3689031.3696076; arXiv 2409.14252, 21 September 2024). Read in full via research pass 2026-09-28. Kleppmann co-created Automerge and Gentle wrote Diamond Types, so this is the CRDT side speaking, which is what synthesis asked for.

What it proposes

The paper treats a collaborative document as an event graph: the set of all edit events and their causal parents. The document is replay(G), a pure function of that graph. Two existing families answer this badly in different ways:

• OT (operational transformation) merges with integer indexes and is cheap in memory, but merging two long offline branches costs O(n²) or worse.
• CRDTs give every character an ID, so merges are cheap, but the per-character metadata must stay in memory whenever the document is open and must be loaded from disk before any edit.

Eg-walker stores and sends only the event graph. It builds a CRDT-like structure only while merging concurrent events, then throws it away. It never writes CRDT state to disk or sends it over the network. Outside a merge it holds only the plain document text.

What it measures

Seven real editing traces, tested against Automerge 0.5.9 (Rust), Yjs 13.6.10 (JavaScript), the authors' own reference CRDT, and an OT library:

• OT's weak case: trace A2 takes about an hour to merge with OT and 24 ms with Eg-walker (160,000×).
• Merge time vs CRDTs: on concurrent traces Eg-walker is about as fast as the reference CRDT. On sequential traces it is 7–10× faster, because it can skip state work at "critical versions". The authors say the larger gap to Yjs and Automerge is due to "implementation differences and not fundamental algorithmic reasons".
• Memory: in the steady state Eg-walker uses 1–2 orders of magnitude less than the best CRDTs. Peak memory while merging is comparable to them.
• Load time: orders of magnitude faster than CRDTs, because Eg-walker loads a cached copy of the text and reads the event graph only when it must merge.
• Storage: its encoded event graph is smaller than Automerge's saved state and, in many cases, smaller than Yjs's, with compression turned off on both for a fair comparison.

What it does to the spoke's sync question

rethinking-data-client-event-sourcing framed sync as event sourcing versus CRDTs, with the claim that event sourcing wins coming from a framework maintainer and no measurement. This paper does not pick a side in that framing. It shows that the fastest text design here is a persisted event log with a transient CRDT. The log is the storage and the sync format, and the CRDT is a merge algorithm. That is closer to event-sourcing than to a stored CRDT, but it was written by CRDT authors and still depends on a CRDT at merge time.

Limits to keep in view. It covers plain text only, not the structured, schema-changing data that the event-sourcing argument was about. All numbers come from the authors' own implementations on their own traces, and nobody outside has re-run them here. The reference CRDT that the paper beats shares most of its code with Eg-walker.

Tier

T1. A peer-reviewed systems paper (EuroSys 2025) with published traces and code. The authors build both competing approaches, so this is a first-party result on a benchmark they chose.

Related

rethinking-data-client-event-sourcing · event-sourcing · local-first-architecture · consistency-models