Why Database Choice Matters

In almost every software system, a database plays a central role. But when it comes to event sourcing, the choice of database is not just a matter of performance or convenience. It is a critical architectural decision that determines whether the approach will scale, remain reliable, and meet compliance requirements.

The Nature of Event Sourcing

Event sourcing is fundamentally different from traditional persistence models:

• It relies on storing every event that has ever occurred.
• It assumes that events are immutable facts that must never change once written.
• It requires the ability to replay events to rebuild the current state or new projections.

Because of these requirements, the database is no longer just a storage backend – it becomes the core of the entire architecture.

Why the Database Becomes Critical

When events are the single source of truth, the database must guarantee more than just durability:

• Consistency under load: Can the database handle millions or billions of events while keeping order intact?
• Scalability: Will it grow with the system without hitting performance limits?
• Reliability: Can it recover from failures without data loss or corruption?
• Compliance: Does it allow retention, deletion, or anonymization of data where legally required?
• Querying: Can it support efficient queries or projections built from historical streams?

If the database falls short in any of these areas, the entire event-sourced system is at risk.

Pitfalls of Using the Wrong Database

Teams often assume they can "just use" an existing database. Common scenarios include:

• Relational databases: Strong in ACID guarantees, but designed for current state rather than infinite append-only streams.
• NoSQL databases: Highly scalable, but often weak in consistency or immutability guarantees.
• Event streaming systems: Excellent for high-throughput messaging, but not optimized for long-term event storage and querying.

Each of these categories may work up to a point, but sooner or later they tend to reveal fundamental limitations when applied to event sourcing.

The Case for Specialized Event Stores

This is why specialized event stores exist: databases built from the ground up to support the requirements of event sourcing. Instead of adapting general-purpose tools, they provide:

• Native support for append-only event streams
• Efficient replay and snapshot mechanisms
• Built-in consistency and ordering guarantees
• Features for compliance, signatures, and validation

Choosing such a solution reduces complexity and ensures that the foundation of the system aligns with the principles of event sourcing.

Conclusion

In event sourcing, the database is not just one component among many – it is the central pillar that either enables or undermines the entire approach. Making the right choice early avoids costly migrations and ensures that event sourcing can deliver on its promises.

Next up: Core Requirements – the essential properties every database for event sourcing must provide.