# 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`](/learn/tutorials/first-steps-with-eventsourcingdb/reading-events)** 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:

```json
{
  "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.