We built a dedicated event store – here's why Kafka and Postgres weren't enough

This guide provides an overview of how EventSourcingDB compares to other types of technologies commonly used to store or process events. While event sourcing is a well-established pattern, many teams implement it using general-purpose tools that were not specifically designed for this purpose.

This document outlines the differences between four major categories of technologies and highlights where EventSourcingDB fits in. You'll learn which trade-offs exist, why certain tools may fall short for event-sourced systems, and when a dedicated event store is the right choice.

Relational Databases¶

Relational databases are the default choice for many applications, offering mature infrastructure, strong consistency, and flexible query capabilities. However, they are designed for normalized, mutable state – not for immutable, ordered event streams.

Implementing event sourcing on top of a relational model typically involves custom tables, manual enforcement of append-only behavior, and additional logic to maintain stream ordering and idempotency. Concurrency handling often relies on ad hoc locking or optimistic concurrency implemented at the application level.

While feasible in simple cases, this approach tends to become fragile and error-prone as systems grow in complexity.

Further information can be found in Consistency Guarantees and EventQL.

NoSQL Databases¶

Document stores and key-value databases are often used for their flexibility and scalability. They can store JSON-like event data and support dynamic schemas, which seems like a good match for event sourcing at first glance.

However, they generally lack native support for ordered streams, transactional guarantees, or consistent concurrency control. Events must be ordered and grouped manually, often using partitioning schemes or naming conventions. Snapshots, versioning, and replay mechanics have to be built from scratch.

This increases operational effort and shifts critical correctness concerns from the infrastructure to the application code.

For additional details, see Scaling and High Availability.

Event-Streaming Platforms¶

Event streaming platforms are powerful tools for distributing events between services. They excel at handling high-throughput, low-latency event flows and offer rich ecosystems for real-time processing. However, they are not designed to act as long-term system-of-record storage for business entities.

While platforms like these can retain events for a configurable period, they typically do not offer stream-level isolation, built-in snapshotting, or schema-aware querying. The focus is on event propagation and transformation, not on consistent state reconstruction.

As a result, implementing full event sourcing requires significant additional infrastructure – especially to handle replay, evolution, and transactional consistency.

Event-Sourcing-Specific Databases¶

Some databases are built explicitly for event sourcing. They typically offer a domain-oriented data model, native support for append-only streams, and features like optimistic concurrency, snapshotting, and event versioning. These tools come closest to solving the actual requirements of event-sourced systems.

However, they are often designed with high scalability and operational robustness in mind, which can make them complex to operate or integrate. Some impose specific architectural assumptions, require dedicated infrastructure, or introduce proprietary protocols and tooling that may not align with every team's needs or preferences.

Where EventSourcingDB Fits In¶

EventSourcingDB was created to address the core needs of event-sourced systems without adding unnecessary complexity. It focuses on storing and querying event streams efficiently and reliably – nothing more, nothing less.

Unlike general-purpose databases, it natively supports immutability, ordering, and stream separation. Unlike streaming platforms, it is optimized for long-term consistency and replay. And unlike some specialized tools, it avoids operational overhead by offering a simple HTTP interface, minimal configuration, and easy deployment.

Each of the technologies described above serves a different purpose and may be the right choice in other contexts. But when your goal is to implement event sourcing cleanly, transparently, and with confidence, a dedicated and focused event store like EventSourcingDB provides the right level of abstraction and support.

More information is available in Why EventSourcingDB and Use Cases.