Built for systems that
remember everything
Four use cases where a mutable database is a liability and an event store is the right foundation.
Audit Trails & Compliance
Immutable history every regulator will accept
Every state change is an append-only event with cryptographic integrity. No silent updates, no lost edits — the full provenance of every record is queryable by timestamp, actor, or entity.
Example
A regulator asks what your system knew about a customer on 2024-09-12. You run a single `as_of` query and hand over the reconstructed state in seconds — not days of log forensics.
- Append-only WAL with CRC32 checksums
- `as_of` queries reconstruct any past state
- Actor + metadata captured on every event
- Compliance-ready: SOC 2, HIPAA, financial audit
Event Replay & Debugging
Reproduce bugs by rewinding history
Stop guessing how production got into a broken state. Replay the exact sequence of events that led to the bug in a staging environment, or time-travel the projection to any past moment.
Example
A checkout silently fails at 2 AM. Replay the last 10 minutes of events for that order id against a fresh projection — the divergence shows up in the first diff.
- Deterministic replay against any projection
- 11.9μs p99 query latency for tight debug loops
- Rebuild projections without dropping data
- Diff two points in time to find what changed
AI Agent Memory
Give LLMs persistent context
Agents that only remember the current conversation are amnesiacs. AllSource gives them a durable memory layer — graph nodes, vector embeddings, and temporal reasoning — accessible via 43 MCP tools.
Example
Your coding agent remembers that two weeks ago you decided to drop a column. Today, when it sees that column referenced in a migration, it flags the regression before you commit.
- 43 MCP tools for Claude, GPT, and custom agents
- Graph + vector + compressed index in one engine
- Shared memory across agents, sessions, machines
- Embedded mode: no cloud dependency
Financial Transaction History
Books that never lose a penny
Ledgers built on mutable rows are a liability. Store every debit, credit, reversal, and correction as an immutable event and derive balances by projection — with full reconciliation built in.
Example
A customer disputes a charge from three months ago. You query the entity's event stream, replay the balance at each moment, and show exactly when and why it moved — with no reconstruction guesswork.
- Append-only ledger — no destructive updates
- 469K events/sec for high-throughput exchanges
- Point-in-time balances via `as_of`
- Corrections are events, not rewrites
Not sure if you need event sourcing?
If you can answer "yes" to any of these, an event store is a better foundation than a mutable database: