Event sourcing
Storing an application’s state as an append-only log of immutable events and deriving the current state by replaying them, instead of storing mutable rows or documents that get overwritten in place. The log is the system of record; the queryable database is a materialized view of it rethinking-data-client-event-sourcing.
Why it matters for operational stores
In a local-first app it doubles as the sync protocol. Clients exchange events rather than rows, and each client materializes its own SQLite state from the log — the design livestore is built on. Two properties follow:
- History is free. Replay gives you the past state of the store, an audit trail, and the ability to reason semantically about what changed and why, not just what the row says now.
- Schema evolution is tractable. Events are stable facts; the materialization can be rewritten. This is the argument for event sourcing over CRDTs when an app’s schema keeps moving or maps in external data from several providers.
Versus CRDTs
The two mechanisms for merging concurrent offline edits, and the live design argument in this corner:
| Event sourcing | CRDTs | |
|---|---|---|
| Unit of sync | immutable event log | mutable auto-merging data structure |
| Strength | evolving schemas, external data mapping, audit/replay | collaborative conflict resolution, simpler mental model |
| Examples | livestore | Automerge, Yjs, Loro |
The claim that event sourcing wins on schema evolution comes from johannes-schickling, who maintains an event-sourcing framework, so treat it as an interested argument rather than a settled result — no benchmark or comparative study is offered.
Related
local-first-architecture · livestore · rethinking-data-client-event-sourcing · operational-databases · online-transaction-processing