Concepts
Event store
Most databases keep the answer. They store how things are right now, and every update overwrites what came before. When the business later asks how it got there, that history is gone.
An event store keeps the history instead. Every change is recorded as an immutable event, in order, and current state is derived from it. A purpose-built event store also validates every new event against that history before accepting it, so business rules hold at the moment of the write.
One row, overwritten
Each change replaces the last value. The row says where the student is today, not how they got there.
| ID | STATUS | COURSES | CITY |
|---|---|---|---|
| s-1 | registered | 0 | Amsterdam |
An ordered history, appended
Each change is an immutable event, written after the last one and never written over.
This page explains what an event store is, what it guarantees, how event store databases differ from the databases and platforms teams often use instead, and what it takes to run one at billions of events.
What is an event store?
An event store is a database that keeps every change in your application as an immutable, ordered event, retrieves one entity’s history efficiently even at billions of events, and validates every new event against that history before accepting it.
Any database can accumulate records, and none of them becomes an event store by doing so. The name is earned by the two operations that must hold under production load. Retrieval has to isolate one entity’s ordered history from billions of records during reads at latencies a live application can tolerate, and every append must be validated against the existing history at write time.
Each change goes after the last one. Recorded events never change.
An index picks out only the events about the entity at hand.
The store rejects an append when the history it was decided on has changed.
What is an event?
An event is a record of something significant that happened in your system, written in past tense, for example RegistrationConfirmed or PaymentRejected. These are facts and are never changed afterwards. What happened, happened. When circumstances change, a new fact is appended after the old one rather than written over it. Each event carries its type, its position in the store, when it was recorded, the identifiers or tags that link it to the entities it concerns, and its payload.
Named for the business fact, not the technical change. Handlers and queries select on it.
How is an event store different from a database?
A traditional database stores the answer, while an event store stores everything that produced said answer. Where a relational database holds an entity’s current status and nothing else, an event store holds every change that produced that status, in sequence, permanently. Applications built on event sourcing derive their current state from those events instead of keeping it in mutable rows.
An event store guarantees consistency at the moment of append, immutability once an event is written, and strict ordering on read. The first is crucial because every new event is checked against the history already recorded, so conflicting facts are rejected before they enter the record rather than untangled after they corrupt it.
History also gives auditors and regulators a complete account of what happened and in which order, without a separate audit log that can drift away from the data it describes.
Keeping history pays off twice. A live application can act on it while a request is still in flight. And when the business asks a question nobody anticipated at design time, the answer is read from the events instead of being wished back into existence.
Can’t I use any database as an event store?
You can. An event store is a log with an index in front of it, and any database can hold a log, one table with a row per event and a position column. Teams have run event-sourced systems on PostgreSQL, SQLite, MongoDB and DynamoDB, and at a small scale it works.
The work is in what you add on top, so that both operations still hold with several writers, several application instances and a few billion events. The two boards below show those pieces for PostgreSQL and for SQLite, the two most common do-it-yourself choices. A piece marked “you build it” is code you write, test and operate. A piece marked “not available” is a limit you design around.
The honest summary is that PostgreSQL gives you a correct event store once you have built ordering, subscriptions, snapshots, retention and failover around it, and SQLite gives you ordering for free because it has one writer, then stops at one machine for the same reason. Axon Server is that list built once, as one system, with the routing that keeps it fast.
Is it slow to event source millions of events?
It would be if systems actually did that on every request, and the reason they do not is a two-layer mechanism. Consider an entity whose history spans five thousand events. With snapshots taken every hundred events, the first four thousand nine hundred are compressed into a single stored state. When a request arrives, the application loads that snapshot, applies only the few dozen events recorded since, and responds fast, without touching the thousands of events underneath.
The second layer is aggregate caching, which removes the event store from the hot path on reads entirely for most cases. When the same instance of an application is always responsible for the same entity, that entity’s state is often still in memory from the last request, so the application applies its decision directly from cache and sends only the resulting append to the store. The consistency check in the event store makes this safe, because it verifies that the application’s view of history is current before accepting the event.
Apply every event since the entity was created.
With a policy of one snapshot per 100 events, events 1 to 4,900 are folded into one stored state.
Same entity, same instance, state still in memory from the last request. The store only verifies the append.
Underneath is the operative word, because those events are compressed out of the hot path, not thrown away. If a bug corrupted the snapshots, the full history still exists to source from scratch and rebuild them correctly, and if a new analytical question arrives, the complete record is there to replay. Snapshots buy speed without spending history.
What does Axon Server add as an event store?
Axon Server brings the pieces teams otherwise build around a general-purpose database into one system.
01
Consistency on every append, per aggregate or across entities with dynamic consistency boundaries.
02
Fast per-entity reads out of billions of events, through dedicated indexes and snapshots.
03
High availability through Raft-based replication groups and dedicated node roles.
04
Histories that grow for years, with tiered storage moving older segments off primary disks.
The broker does not know which instance holds the order’s state.
The routing key sends every command for o-7 to the same instance, as long as the set of instances is stable.
instance 1
instance 2
instance 3
How does Axon Server store events?
Axon Server is built around an append-only log. Its storage is organized in layers, each with one job.
First, events are appended to segment files. Each context has its own event store on disk. New events are written to the end of the current segment, 250 MB by default, and closed segments are never changed in place. Every event receives a position in one global sequence.
Second, indexes find one entity’s history. In aggregate-based contexts, a global index locates an aggregate’s latest event, and per-segment pointers lead back to the earlier ones, skipping the segments in between. Contexts built for dynamic consistency boundaries (DCB) use a different index, one built to answer criteria over tags and event types.
Third, snapshots live in their own store. A snapshot holds the computed state of an entity at a known position, so loading it means reading the snapshot and only the events recorded after it, in one operation. The application decides when to take a snapshot. Since Axon Server 2026.1, DCB contexts source snapshot and events together as well.
Fourth, older data can move to other tiers. On each node, tiered storage moves closed segments to other storage based on time or size, so recent segments stay on fast disks and older ones on cheaper storage, while the full history stays readable. With secondary nodes in the cluster, primary nodes can drop the oldest data entirely.
New events go to the end of the current segment. Closed segments are never changed in place.
segment 1CLOSED
segment 2CLOSED
segment 3CLOSED
segment 4OPEN
In aggregate-based contexts, a global index points to the latest event and per-segment pointers lead back, skipping segments in between. DCB contexts use a different index.
Computed state at a known position, kept in its own store. The application decides when to take one.
Closed segments move off primary disks by age or size.
PRIMARY · FAST DISK
OTHER TIER · ARCHIVE
The index returns only student s-1’s events, folded into current state.
A cursor reads the whole log in order to build a view nobody planned for.
FOLDED FROM 0 EVENTS
Reading follows the two paths the figure shows. Sourcing reads one entity’s events, bounded and fast, to make a decision. Streaming reads the global log from a tracking token onward, which is how event processors keep projections up to date and how a replay rebuilds a view from the very first event.
How does an event store keep appends consistent?
Every append to Axon Server can carry a condition. Before an event reaches the store, the application decides what has to be true for that event to be valid and attaches that requirement to the append. The store evaluates the condition against the current history at the moment the append arrives, rather than trusting whatever the application assumed was true when it issued the request. If the condition fails, nothing is written, and the application re-reads and decides again. No cleanup job, no deduplication logic downstream, and no idempotency key bolted on.
In aggregate-based contexts, the condition is the aggregate’s sequence number, so two writers that both read sequence 41 cannot both append 42. In DCB contexts, it is an append condition made of event criteria over tags and types plus the consistency marker returned when the events were read. The append fails if any event matching the criteria arrived after that marker.
The second form lets one rule span several entities, such as a course’s capacity and a student’s subscription limit, without sagas and without fixing aggregate boundaries before the first event is written.
Two writers that read sequence 41 cannot both append 42.
Criteria over tags and types, plus the marker from the read.
WRITER AREAD
loaded order o-7 at sequence 41
WRITER BREAD
loaded order o-7 at sequence 41
How does Axon Server stay available?
In a cluster, Axon Server nodes form replication groups that use the Raft protocol. Each group elects a leader, and an append is confirmed once a majority of the group’s primary nodes has stored it, plus any active backup nodes the group is configured to wait for, so losing one primary node out of three costs neither data nor availability. Nodes can also take other roles. Active and passive backup nodes keep copies of the event store for recovery, secondary nodes keep the full history so primary nodes only need to hold recent segments, and messaging-only nodes route messages without storing events. Clients reconnect to another node automatically.
axonserver-1LEADER
writes event 7
axonserver-2
waiting
axonserver-3
waiting
Why one system
for events and messages
Because in a live event-sourced system, where a message is handled determines how fast the history can be used. Applications do not exchange only events, since a command such as “change my address” is the intent to do something, and the event is the proof that it happened. That intent has to reach the right place, because aggregate caching only works when requests for the same entity consistently land on the same application instance, where that entity’s state is already warm in memory. Route the command elsewhere and the cache is cold, the application sources from scratch, and the speed the architecture promised evaporates.
Splitting storage and routing across two systems means keeping two views of ownership and order aligned with each other, which is yet another distributed-systems problem acquired for no benefit. Combining them means the knowledge exists once, which is why Axon Server embodies both jobs in a single integrated system.
The same history also feeds analysis. Axoniq Insights lets data and business teams query event history directly, so a new question does not have to become a new projection.
How do event stores compare?
Many systems can hold events. Fewer are designed around the operations that define an event store. The table compares Axon Server with other purpose-built event stores, event sourcing libraries, general-purpose databases used as event stores, and two systems that are often mistaken for one. It reflects each product’s public documentation as of November 2026.
| System | Built for event sourcing | Optimistic append | DCB append conditions | Per-entity reads | Global order | Catch-up subscriptions | Snapshots | Clustering and HA | Event transformation | Command and query routing | License and hosting |
|---|---|---|---|---|---|---|---|---|---|---|---|
| PURPOSE-BUILT EVENT STORES | |||||||||||
| Axon ServerAxoniq | Yes | Yes | Yes1 | Yes | Yes | Yes | Yes | Yes2 | Yes2 | Yes | Free for non-production, paid self-hosted plans, managed cloud |
| KurrentDBformerly EventStoreDB | Yes | Yes | Partial3 | Yes | Yes | Yes | No, pattern | Yes4 | Partial5 | No | Source-available Kurrent License, Kurrent Cloud |
| EventSourcingDBthe native web | Yes | Yes | Yes | Yes | Yes | Yes | No, pattern | No6 | No | No | Closed source, free up to 25,000 events |
| UmaDBDCB-native store | Yes | Yes | Yes | Yes, by query | Yes | Yes | n/a, undocumented | n/a, undocumented | n/a, undocumented | No | MIT or Apache 2.0, self-hosted |
| EVENT SOURCING LIBRARIES | |||||||||||
| Marten.NET library on Postgres | Yes | Yes | Yes | Yes | Partial7 | Yes | Yes | Partial, via Postgres | Yes, masking | No | MIT, runs on any Postgres |
| Akka PersistenceJVM library | Yes | Partial8 | No | Yes | No | Yes | Yes | Yes, Akka Cluster | Partial, adapters | Partial8 | BSL 1.1, Akka platform |
| GENERAL-PURPOSE DATABASES USED AS AN EVENT STORE | |||||||||||
| PostgreSQLappend-only table | No | DIY9 | DIY | Yes, index | DIY9 | DIY | DIY | Partial9 | DIY | No | PostgreSQL License, many managed offerings |
| MongoDBevent documents | No | DIY | DIY | Yes, index | No | Partial10 | DIY | Yes, replica sets | DIY | No | SSPL, MongoDB Atlas |
| Amazon DynamoDBevent items | No | Yes, conditions | Partial11 | Yes | No | Partial11 | DIY | Yes, managed | DIY | No | Proprietary, AWS only |
| Azure Cosmos DBevent documents | No | Yes, ETag | Partial12 | Yes | No | Partial12 | DIY | Yes, managed | DIY | No | Proprietary, Azure only |
| OFTEN MISTAKEN FOR AN EVENT STORE | |||||||||||
| Apache Kafkastreaming platform | No | No13 | No | No13 | No, per partition | Yes | No | Yes | No13 | No | Apache 2.0, Confluent Cloud, Amazon MSK |
| Temporalworkflow persistence | No14 | n/a | n/a | n/a | n/a | n/a | n/a | Yes | n/a | n/a | MIT, Temporal Cloud |
Scroll sideways to see every column.
- Axon Server. DCB contexts append with an append condition: event criteria over tags and types plus a consistency marker. Fully supported since 2025.2, and existing contexts can be converted since 2026.0. DCB is a licensed capability, available from the Team plan upward.
- Axon Server. Clustering and replication groups depend on the license. Persistent Event Transformation replaces or deletes events in aggregate-based contexts; since 2026.1, transformed contexts can be converted to DCB as well.
- KurrentDB. Multi-stream appends check an expected version per stream. Since 26.1 an append can also carry expected versions for streams it does not write to. That covers some cross-entity rules, but conditions are stream-based, not tag or query based.
- KurrentDB. Clustering requires an Enterprise license from version 26.2, per Kurrent’s licensing announcement.
- KurrentDB. Redaction is a separate tool run against a running server, once per node: licensed through 26.1, free from 26.2. Streams can be deleted or truncated and scavenged.
- EventSourcingDB. The documentation states high availability is planned, not yet available.
- Marten. The global sequence is a Postgres sequence, which can have gaps. The async daemon tracks a high water mark to handle them.
- Akka Persistence. Consistency comes from a single writer per entity through Cluster Sharding, not an expected version from the client. Sharding routes commands to entities, but there is no command or query bus.
- PostgreSQL. Expected versions usually mean a unique (stream, version) constraint. Sequences are not transactional, so positions can have gaps and become visible out of commit order. Automatic failover needs external tooling or a managed service.
- MongoDB. Change streams give live subscriptions, but resuming depends on oplog retention, so catching up from the first event is up to you.
- DynamoDB. Transactions with condition checks across up to 100 items can emulate some multi-entity rules. Streams keep records for 24 hours.
- Cosmos DB. Transactional batches are atomic within one logical partition key, and the change feed is ordered per partition key.
- Kafka. A producer cannot append on the condition of an expected offset, reading one entity means scanning a partition, and records cannot be rewritten in place.
- Temporal. A durable workflow engine. Its event history is an internal log per workflow execution, stored in Cassandra, MySQL or PostgreSQL and capped at 51,200 events. It is not a store for application domain events.
Get Started with Axoniq
Run your event store on Axon Server
Validated appends and fast per-entity retrieval are the operations a general-purpose database makes you build. Axon Server brings storage, consistency, replication and routing into one system, so your team spends its time on the business problem.
![](data:image/svg+xml,<svg display="block" role="presentation" viewBox="0 0 592 505" xmlns="http://www.w3.org/2000/svg"><path d="M 60 155.5 L 60 133.5 C 60 116.932 60 100 90 100 C 120 100 120 82.5 120 60 L 120 37 C 120 20.431 120 0 150 0 C 180 0 180 20.431 180 37 L 180 65.931 C 180 82.5 180 100 210 100 C 240 100 240 82.5 240 65.931 L 240 37 C 240 20.431 240 0 270 0 C 300 0 300 20.431 300 37 L 300 60 C 300 83 300 100 270 100 C 240 100 240 116.931 240 133.5 L 240 155.5 C 240 172.069 240 200 270 200 C 300 200 300 222.432 300 239 L 300 261 C 300 287.5 300 300 270 300 C 240 300 240 288 240 271.431 L 240 239 C 240 222.432 240 200 210 200 C 180 200 180 222.432 180 239 L 180 261 C 180 288 180 300 150 300 C 120 300 120 287.5 120 270.931 L 120 239 C 120 222.432 120 200 150 200 C 180 200 180 172.069 180 155.5 L 180 133.5 C 180 116.932 180 100 150 100 C 120 100 120 116.931 120 133.5 L 120 155.5 C 120 172.069 120 200 90 200 C 60 200 60 222.432 60 239 L 60 270.931 C 60 287.5 60 300 30 300 C 0 300 0 287.5 0 261 L 0 239 C 0 222.432 0 200 30 200 C 60 200 60 172.069 60 155.5 Z" fill="rgb(0, 0, 0)" height="300px" id="PUlF9PxPI" transform="translate(146 0)" width="300px"/><path d="M 0 103.917 L 36.942 1.41 L 61.335 1.41 L 98.136 103.917 L 76.281 103.917 L 66.834 76.845 L 22.701 76.845 L 12.831 103.917 Z M 26.79 65.424 L 62.886 65.424 L 45.12 14.523 Z M 171.284 103.917 L 143.789 63.732 L 114.743 103.917 L 99.938 103.917 L 136.598 53.016 L 101.348 1.41 L 126.164 1.41 L 151.826 38.916 L 178.757 1.41 L 193.562 1.41 L 159.017 49.632 L 196.1 103.917 Z M 297.837 52.734 C 297.837 82.908 280.353 105.468 249.051 105.468 C 217.608 105.468 200.265 82.908 200.265 52.734 C 200.265 22.419 217.608 0 249.051 0 C 280.353 0 297.837 22.419 297.837 52.734 Z M 221.274 52.734 C 221.274 72.897 228.465 93.483 249.051 93.483 C 269.637 93.483 276.828 72.897 276.828 52.734 C 276.828 32.43 269.637 11.985 249.051 11.985 C 228.465 11.985 221.274 32.43 221.274 52.734 Z M 405.589 1.41 L 405.589 103.917 L 382.042 103.917 L 333.256 18.471 L 334.243 103.917 L 314.362 103.917 L 314.362 1.41 L 337.909 1.41 L 386.695 86.715 L 385.708 1.41 Z M 430.77 103.917 L 430.77 1.41 L 450.651 1.41 L 450.651 103.917 Z M 573.246 91.932 L 573.246 105.468 L 516 105.468 C 485.544 105.468 468.06 82.344 468.06 52.311 C 468.06 22.842 484.275 0 516.564 0 C 547.02 0 565.491 21.573 565.491 51.747 C 565.491 69.09 557.877 85.305 545.187 95.034 C 554.352 93.201 563.376 91.932 573.246 91.932 Z M 489.069 52.17 C 489.069 75.153 496.965 94.188 516.564 94.188 C 537.432 94.188 544.482 73.038 544.482 52.311 C 544.482 28.764 535.599 11.985 516.564 11.985 C 497.106 11.985 489.069 30.738 489.069 52.17 Z" fill="rgb(0, 0, 0)" height="105.46799999999996px" id="g7P19tPZB" transform="translate(8.294 399.083)" width="573.2455397949218px"/></svg>)