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
- Financial Ledgers: Regulatory and compliance needs demand an immutable, replayable record of every transaction, not just the latest balance.
- Debugging Production Issues: Replaying events lets you reconstruct the exact state of an entity at any past point in time.
- CQRS Architectures: The event stream naturally feeds multiple independent read-model projections tailored to different queries.
State-Based Persistence
- CRUD Admin Panels: Simple direct reads and writes against current data are sufficient and avoid the overhead of replay logic.
- High-Write Simple Entities: Avoids unbounded log growth for entities with frequent, low-value updates like counters or status flags.
- Ad-hoc Reporting: Analysts can run SQL directly against current-state tables without building and maintaining projections.