What is an event store database?
An event store database records ordered, immutable facts about state changes. Instead of keeping only the latest value, it preserves the sequence that produced that value. Applications derive current state through projections, trace results back to source events, and replay history to reconstruct earlier state.
Event sourcing is the model; the event store is the database
Event sourcing models application state as a sequence of accepted events. An event store database supplies the storage rules that model needs: ordered streams, append-only writes, version checks, durable positions, replay, and historical reads. Current-state tables and caches remain useful read models, but they are derived views rather than the only surviving record.
| System | Source of truth | Historical answer |
|---|---|---|
| Event store database | Ordered domain events | Replay stream to sequence or timestamp |
| Current-state database | Latest stored values | Needs audit tables, snapshots, or backups |
| Application logs | Operational messages | Can explain execution but may not rebuild state |
Four parts of the model
Events are facts
Each accepted event records what changed, when it changed, and which stream it belongs to. Corrections append another event; they do not edit history in place.
Streams preserve order
Related events form a stream, commonly scoped to one entity or process. Stream versions support optimistic concurrency and deterministic replay.
Projections answer reads
A projection folds events into a read model: account balance, order status, agent memory, dashboard totals, or any other current-state view.
Replay reconstructs state
Because source events remain available, systems can rebuild a projection, inspect a past point in time, or test corrected logic against recorded history.
Use one when history matters
- Audit and compliance need a traceable sequence of decisions.
- Projections must be rebuilt after logic changes.
- Operators need point-in-time answers or replay debugging.
- Agents must retain provenance across sessions.
Do not use one by default
A current-state database is usually simpler when overwriting rows is acceptable and you do not need replay, provenance, temporal queries, or multiple derived read models. Event sourcing adds modelling, versioning, and projection work; those costs need a real reason.
How AllSource maps the event-store model
AllSource Core accepts events into immutable streams backed by a checksummed write-ahead log and Parquet persistence. Query Service derives tenant-facing HTTP, realtime, analytics, and projection reads. Prime builds provenance-aware agent memory from the same durable history. Event payloads remain in the event store; product analytics receives only fixed interaction names and aggregate-safe properties.