Skip to content

Core Requirements

Before looking at specific categories of databases, it is important to understand the core requirements that any system must fulfill in order to be suitable for event sourcing. These requirements define the foundation of an event store and help distinguish between general-purpose databases and specialized solutions.

Append-Only Storage

At the heart of event sourcing lies the principle of append-only storage.

  • Events must always be written in sequence.
  • No existing record may be overwritten or deleted.
  • The database must guarantee that events are stored reliably and in the correct order.

Without this guarantee, the event history can be corrupted, making it impossible to reconstruct the truth of what happened.

Immutability

Events are facts of the past. Once recorded, they must never change. The database therefore has to enforce immutability:

  • Preventing updates or modifications to existing events.
  • Ensuring that historical data remains verifiable and tamper-proof.
  • Supporting compliance measures (such as GDPR) without breaking the immutability principle.

Immutability is what gives event sourcing its power as an auditable and trustworthy model.

Replay Capability

One of the most powerful features of event sourcing is the ability to replay events:

  • Rebuild the current state of an aggregate from scratch.
  • Generate new projections for queries that were not anticipated at design time.
  • Recover from software defects by applying corrected logic to the full history.

If a database cannot efficiently support replay, it fails to deliver on the promise of event sourcing.

Consistency and Ordering

In distributed systems, maintaining a consistent order of events is not trivial. A suitable event store must provide:

  • Strict sequencing of events within a stream.
  • Guarantees that readers see events in the order in which they were written.
  • Support for concurrency control, ensuring that conflicting writes are detected and handled.

Observability of Events

Event sourcing is not only about persisting history but also about reacting to new events as they happen. A suitable event store should:

  • Provide built-in mechanisms for subscriptions or event feeds.
  • Allow downstream systems to consume events reliably without resorting to the Transactional Outbox Pattern.
  • Ensure that published events are consistent with the persisted event history.

This makes it possible to integrate with other systems in a clean and robust way.

Query Capabilities

Storing events is not enough – systems also need to query events efficiently:

  • Searching for events by type, aggregate, or correlation ID.
  • Filtering by time ranges or metadata.
  • Supporting ad-hoc analysis and debugging through expressive query languages.

Without query capabilities, developers are left with costly workarounds and reduced visibility into the system's behavior.

Scalability and Performance

Event sourcing systems can easily generate millions or billions of events over time. A suitable database must:

  • Scale horizontally to handle ever-growing event streams.
  • Provide predictable write performance under heavy load.
  • Allow for efficient queries across large volumes of historical data.

Security and Compliance

Finally, an event store must align with organizational and legal requirements:

  • Strong guarantees against unauthorized modification.
  • Mechanisms for encryption and signature validation.
  • Support for compliance measures such as retention rules or anonymization.

Conclusion

These requirements form the baseline against which any database option should be measured. They highlight why event sourcing demands more than a conventional database can typically provide.

Next up: Relational Databases – evaluating the strengths and weaknesses of traditional relational systems for event sourcing.