Event Sourcing vs State-Based Persistence: Storing Changes vs Storing Current State
Overview Event sourcing persists every change to an entity as an immutable, ordered event log, deriving current state by replaying that history. State-based persistence instead stores and overwrites a single current record, discarding prior values on each update. The choice affects auditability, storage growth, and how much replay/projection machinery you need to build. Comparison Diagram Event SourcingAccountOpenedDeposited $100Withdrew $30Deposited $50replayBalance: $120Full history preservedState-Based PersistenceBalance: $0Balance: $100Balance: $70overwriteBalance: $120Only latest state kept Comparison Table Aspect Event Sourcing State-Based Persistence Write operation Appends a new immutable event to the log; nothing is ever modified in place Updates or overwrites the existing row/record with new values Data representation Sequence of domain events describing what happened Single current snapshot of the entity’s fields Reading current state Replay events from the start (or from a snapshot) to derive current state Direct read of the stored row, no reconstruction needed Concurrency conflicts Detected by checking the expected event stream version before appending Detected via optimistic locking (row version/timestamp) or DB-level locks Historical/audit trail Native and complete — every past state is reconstructable Not retained by default; requires a separate audit log or triggers Schema evolution Old event versions must be upcast or handled explicitly by consumers Existing rows are migrated or altered directly to the new shape Storage growth Grows unbounded with every change; needs snapshotting/compaction to stay fast Stays roughly proportional to the number of entities, not their history Query complexity Ad-hoc queries need dedicated projections/read models built from the events Supports direct ad-hoc SQL queries against the current data Key Differences Event sourcing stores an append-only event log; state-based persistence stores only the current row Rebuilding state requires replay in event sourcing, versus a simple read in state-based systems Event sourcing gives a native audit trail; state-based needs bolt-on logging to recover history Concurrency is resolved via event versioning instead of row-level locking Storage grows unbounded without snapshots in event sourcing, while state-based storage stays compact When to Use Each Event Sourcing ...