Skip to content

Relational Databases

Relational databases are among the most widely used technologies in software development. Their maturity, strong guarantees, and broad ecosystem make them the default choice for many applications. When considering event sourcing, relational databases are often the first option teams look at – sometimes because they already have them in place, sometimes because of their reputation as reliable and well-understood systems.

The Strengths

Relational databases bring several advantages to the table:

  • ACID guarantees: Strong support for atomicity, consistency, isolation, and durability.
  • Mature technology: Decades of optimization, wide availability, and proven reliability in production environments.
  • Rich query capabilities: SQL provides a powerful and standardized language for querying and analyzing data.
  • Ecosystem and tooling: Widespread driver support, monitoring tools, and operational expertise make them easy to adopt.
  • Transactional safety: Complex business transactions can be expressed and enforced at the database level.

These strengths explain why relational databases are so deeply entrenched in enterprise systems.

The Limitations

However, when applied to event sourcing, relational databases face significant challenges:

  • Append-only at scale: Tables grow quickly when every event is stored as a row. Without careful partitioning and indexing, write and read performance degrades over time.
  • Immutability: While relational databases allow inserts and updates, enforcing immutability requires custom conventions or triggers, which are easy to bypass.
  • Replay performance: Rebuilding aggregates from millions of rows can be slow and resource-intensive, especially without native replay support.
  • Event ordering: Ordering must be managed manually, often through monotonically increasing IDs or timestamps, which are not always reliable under concurrency.
  • Observability: Relational systems lack built-in mechanisms for event subscriptions, so teams often implement the Transactional Outbox Pattern to propagate changes – adding complexity and operational burden.
  • Schema management: Events evolve over time, but relational schemas are rigid, making versioning and migration difficult to handle gracefully.
  • Scalability: While relational databases scale vertically, true horizontal scaling for massive event volumes is hard to achieve.

These limitations do not necessarily make relational databases unusable, but they do mean that teams must build substantial infrastructure around them to approximate the behavior of a purpose-built event store.

Conclusion

Relational databases are robust, well-understood, and provide excellent querying capabilities. Yet, when used as event stores, they often reveal fundamental mismatches with the requirements of event sourcing. While they can serve as a starting point or for smaller systems, they are rarely a sustainable long-term solution for large-scale, event-sourced architectures.

Next up: NoSQL Databases – exploring how non-relational systems address some of these challenges, and what new trade-offs they introduce.