Notion replaced last-write-wins inside a block with an RGA CRDT
Victoria Shinder2 min readNotion has published how its editor stopped losing people's text. The engineering post is at https://www.notion.com/blog/how-notion-handles-concurrent-editing-with-crdts, and the admission at the top is the interesting part: until 2025 the product was not really collaborative, in the specific sense that two people editing the same block could lose one of the two edits.
The old behaviour was last write wins on a block record. Two concurrent updates arrived at the server, each unaware of the other, and whichever landed second became the truth. The reason nobody noticed constantly is structural: a Notion page is many blocks, each its own database record, so people editing different paragraphs never collided. The collision only happened inside one block — and the more collaborators, the likelier it got.
Offline mode is what forced the issue. Someone editing a page while disconnected could lose everything they wrote if others touched the same blocks before they reconnected. A queue of changes replayed against a last-write-wins store is a data-loss machine.
The fix is a sequence CRDT based on Replicated Growable Array. Every character ever inserted is a node in a tree with a stable, unique ID; Notion calls the nodes text items and the IDs they reference origins, and insert or delete operations point at those IDs rather than at positions. Deletion does not remove anything: the item is marked as a tombstone, because operations still in flight — or sitting on an offline client — may reference the IDs of characters that are already gone, and without them there is nowhere to apply the operation.
The post is candid about the limit: merging without loss is not the same as preserving intent. If two people rewrite the same phrase, the merge keeps both edits and neither person's sentence. That is acceptable mostly because, in a long document, people are usually working in different places.
What it means
A data model can hide a correctness bug for years, and then a feature exposes it. Block-per-record made concurrent editing look fine while the merge strategy underneath was "the loser's text is discarded". Nothing was wrong with the observation — page edits really did merge — the observation was just measuring the wrong unit. Offline mode did not introduce the bug; it removed the thing that was masking it.
Tombstones are the price of referential integrity, and they are permanent. Once operations reference character IDs, you cannot delete the characters, only mark them. Every CRDT text document therefore grows monotonically with editing, not with content, and every team that ships one eventually builds compaction. Worth knowing before you choose the structure, not after.
And "no data loss" is a weaker promise than it sounds. A CRDT guarantees that everyone's operations survive and that all replicas converge. It does not guarantee the result is a sentence anyone wrote. Notion says so plainly, which is more than most explanations of this technology manage.