Event Sourcing vs State-Based Persistence: Storing Changes vs Storing Current State

Tue, 04 Aug 2026 05:10:16 +0900

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

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

Event-Sourcing on IT Comparison

Event Sourcing vs State-Based Persistence: Storing Changes vs Storing Current State

Overview

Comparison Diagram

Comparison Table

Key Differences

When to Use Each