Snapshots

This guide explains how snapshots work in EventSourcingDB – or more precisely, how they don't. Unlike some event stores, EventSourcingDB does not provide a dedicated snapshot mechanism. Instead, snapshots are modeled as regular events and interpreted as such by the application.

You'll learn when snapshots make sense, how to implement them, and how to use them to optimize event replay – without introducing unnecessary complexity.

What Is a Snapshot?

A snapshot is a summary of a subject's state at a particular point in time. It exists to speed up replay: instead of reading and processing all events from the beginning of a stream, the application can start from a snapshot and apply only the events that came after.

But in EventSourcingDB, there is no built-in snapshot feature. A snapshot is simply an event – typically of a special type – that your application recognizes as a known state. The database does not treat it differently from any other event.

This approach keeps the core system simple and avoids premature assumptions about how snapshots should be handled.

When to Use Snapshots

Snapshots are a performance optimization. You should only introduce them when you have concrete evidence that replaying all events for a subject is causing measurable performance issues.

This is rarely the case in practice. Most event streams are not long enough to justify snapshotting. And if a subject contains tens or hundreds of thousands of events, it's worth asking whether the domain model might benefit from restructuring – splitting large aggregates into smaller ones, for example.

Avoid snapshotting as a default strategy – be cautious and deliberate. Apply it only where needed.

Modeling Snapshots as Events

Since snapshots are modeled as regular events, you can store them like any other domain event – just give them a specific event type that indicates their role. For example:

io.eventsourcingdb.library.book-inventory-snapshot

This makes it easy to distinguish snapshot events from regular ones and enables the use of different snapshot types for different use cases.

You can also define snapshots based on domain concepts. Examples include:

• Monthly or yearly financial statements
• Inventory counts after a restocking operation
• State captures before a planned system migration

By anchoring snapshots in domain events, you preserve traceability while making replay more efficient.

Replaying from a Snapshot

To replay from the latest snapshot, you can use the fromLatestEvent feature in EventSourcingDB. It allows you to read all events starting from the most recent event of a given type.

This means you don't need to manually find the latest snapshot or track its position – you just specify the snapshot type as your starting point.

For example, to replay all events for a subject starting from its last snapshot:

{
  "subject": "/books/42",
  "fromLatestEvent": {
    "type": "io.eventsourcingdb.library.book-inventory-snapshot"
  }
}

This returns the most recent snapshot and all subsequent events, in order – ready for your application to process.

Using Snapshots Effectively

• Use snapshots sparingly – only where proven performance needs exist.
• Structure snapshots as regular events with dedicated types.
• Align snapshot logic with domain meaning – don't treat them as mere technical artifacts.
• Combine snapshots with fromLatestEvent for efficient and elegant replays.
• Reconsider aggregate structure before resorting to snapshots as a workaround.

Rethinking Snapshots

Because EventSourcingDB treats snapshots as just another kind of event, there's no special infrastructure, no extra rules, and no magic. This gives you full control over how and when to use them – and keeps the core system lean and focused.

Snapshots are powerful, but they're not always necessary. Used with care, snapshots can improve performance without sacrificing traceability or clarity in the domain model.