Using a Database for Event Sourcing: 5 Hard Truths

Generic databases seem like the path of least resistance. A quick way to get started without adding new technology to the stack. But this path often leads to a dead end as teams push forward, only to hit unexpected performance walls, operational complexity, and architectural rigidity. The very tool they trusted becomes a bottleneck, and the initial simplicity gives way to a constant struggle against the database's fundamental design.

This article is a guide to the non-obvious truths about purpose-built event sourcing platforms. These are the lessons most teams only learn after experiencing significant pain with a DIY approach. It's about moving beyond a simple log of events to a system that governs truth, scales correctness, and allows your architecture to evolve with your business.

New to the pattern itself? Start with our guide to event sourcing. This piece assumes you've decided to do it and are choosing where to put the events.

Can You Use a Regular Database for Event Sourcing?

Yes, and many teams do. A relational database like PostgreSQL or a document store like MongoDB will hold an append-only event log perfectly well at low volume, and starting there is a reasonable decision rather than a naive one.

The problems are not visible at the start. They appear at a few million events, when the access patterns event sourcing depends on — reading a full stream, rebuilding a projection, enforcing consistency across concurrent writers — stop being things a general-purpose database is shaped for.

The five sections below are the specific walls teams hit, in the order they usually hit them.

PostgreSQL as an Event Store Hits a Performance Wall. Hard.

When comparing a purpose-built event store to a generic database, the performance difference isn't incremental, it's a change in category. While benchmarks can be misleading, the data here tells a clear story of architectural mismatch.

Generic relational databases like PostgreSQL can deliver high throughput initially. However, benchmark findings show they inevitably hit a "performance wall," often around 1-2 million events. At this point, write speeds can plummet from thousands of events per second to a crawl of approximately 250. This is not a gradual decline; it's a catastrophic drop-off.

In stark contrast, a purpose-built platform like Axon Server is engineered for the unique append-only workload of event sourcing. It can maintain constant high throughput, handling tens or even hundreds of thousands of events per second, regardless of whether the store contains one million or one billion events.

This extends to storage efficiency. The same benchmarks show that after 100 million events, a bloated PostgreSQL instance can consume 1.8 TB of disk space. Axon Server, with its optimized serialization, stores the same data in just 490 GB—nearly 5x smaller (Based on the Digital Frontiers benchmark comparing Axon Server and PostgreSQL performance over 100 million events).

Analysis: This is surprising because developers are accustomed to the remarkable versatility of relational databases. However, the core patterns of event sourcing—immutable, append-only writes and sequential stream reads—fundamentally conflict with the design of a typical RDBMS, which is optimized for random I/O, in-place updates, and complex indexing via B-Trees. The database is forced to fight its own nature, leading to index bloat, expensive maintenance operations (VACUUM), and ultimately, systemic slowdown.

Scaling an Event Sourcing Database Isn't About Throughput, It's About Correctness

The conventional view of scaling is simple: add more nodes, partition the data streams, and shard the database. This is a story about scaling data. But in a complex, distributed system, the most critical challenge isn't just scaling raw speed, it's scaling while maintaining correctness.

A purpose-built event sourcing platform is designed to scale coordination and correctness. It redistributes responsibility across a cluster without weakening the system's guarantees. This includes preserving essential properties like single-writer guarantees for business aggregates and providing context-aware clustering that understands your architecture's boundaries.

Most systems scale throughput. Axon Server scales correctness.

Analysis: This is impactful because in most distributed systems, adding nodes pushes the burden of ensuring correctness onto the application developers. Teams are forced to invent complex, brittle workarounds for routing commands to the right instance, preventing race conditions, and managing distributed state.

A platform that scales correctness natively eliminates this entire class of problems. It prevents architectural drift and allows teams to grow their system without their code becoming a minefield of defensive checks and complex coordination logic. Axon Server is industry-leading because it scales responsibility, not just data.

Your Event Sourcing Database Design Can Evolve Without a Total Rewrite

Architects are often forced to make monumental, irreversible decisions early in a project's lifecycle: "Is this a monolith or a microservice? Is this interaction strongly or eventually consistent?" Getting these decisions wrong can lead to costly rewrites or trap a business in a rigid, underperforming architecture.

A true event sourcing platform provides the tools to escape this trap. By introducing concepts like Multi-Context Isolation, different business domains can be treated as isolated "event universes," each with its own rules, operational lifecycle, and consistency guarantees.

Layered on top of this, Dynamic Consistency Boundaries (DCBs) grant a genuine architectural superpower: the ability to change the consistency model of an operation at runtime, without redeploying code or refactoring the system. For example, a critical new payments feature can be launched with strict, transactional consistency for maximum safety. As it scales and proves stable, its boundaries can be relaxed at runtime to favor performance. Later, during a high-stakes audit or a security incident, those same boundaries can be temporarily tightened again—all without a single line of code being redeployed.

This highlights the fundamental difference between platforms that merely store data streams and those that govern the meaning of that data. As a direct comparison illustrates:

KurrentDB stores events. Axon Server governs truth.

Analysis: Strategically, this transforms architecture from a static, rigid blueprint into a dynamic system that adapts with the business. It enables what can be called temporal architecture, which is an architecture that evolves over time. You are no longer locked into your day-one decisions. You can start with the safest, simplest model and gracefully evolve it as you learn more about your domain and as your operational needs change, all without the risk and expense of a total rewrite.

An Event Store Lets You Fix Bugs with Replay, Not Risky Repair Scripts

In a traditional state-based system, correcting bad data is a high-stakes nightmare. It involves "data surgery": writing manual, high-risk SQL scripts, performing partial backfills, and deploying a hotfix with the hope that you've identified the full blast radius of the problem. Every step is fraught with the risk of making things worse.

Event sourcing fundamentally changes this because the event log is the immutable, chronological source of truth, recovery becomes a controlled, repeatable, and deterministic operation.

The process is simple and safe:

1. Fix the code in the component that generates the incorrect read model.

2. Reset the projection (the read model) back to a clean state.

3. Replay events from the immutable log through the corrected logic to rebuild the projection correctly.

A dedicated event store turns recovery into replay, not repair.

Analysis: This capability fundamentally changes the nature of operational risk. Data recovery is no longer a "best effort" emergency procedure but a predictable, testable, and automatable workflow. It reduces the number of incidents that require manual, high-pressure intervention and gives teams absolute confidence that a fix is complete and correct. You're not patching state; you're regenerating it from a perfect history.

What Belongs in an Event Store? You Might Be Thinking About Events All Wrong

What should actually be stored in your event store? The answer reveals a subtle, but vital architectural distinction. Not all events are created equal, and treating them as such can turn your event store from a pristine source of truth into a noisy data dump.

There is a key difference between Domain Events and Observations.

• Domain Events: These are facts of true business significance. An event like BikeRented represents a decision or a state transition that matters to the business logic. These are the source of truth, are typically stored indefinitely, and are used to reconstruct state and make future business decisions.

• Observations: These are raw data points or snapshots of a state. A constant stream of LocationUpdated GPS coordinates from a bike is a perfect example. While valuable for analytics, these individual data points are not the source of truth for the core business logic. They are just raw data.

Observations are translated into Domain Events only when they trigger a meaningful business rule. For instance, a stream of location observations might be processed, and only when the bike leaves a predefined geofenced area does the system generate a BikeLocked domain event. That event—not the raw GPS data—is the business fact that gets stored in the event store.

Analysis: This distinction acts as a powerful architectural filter. It ensures that your system of record contains only validated, meaningful business facts. By preventing the event store from becoming a high-volume dumping ground for raw sensor data or analytics pings, you preserve its integrity as a clean, governable source of truth that accurately reflects the history of your business.

Choosing the Best Database for Event Sourcing

Choosing a purpose-built event sourcing platform over a generic database is not a simple performance upgrade. It is a fundamental shift in how you manage the core tenets of your system: correctness, evolution, and operational safety.

The hard-won truths reveal that a true event store isn't just a faster database. It's an active coordinator that scales correctness along with throughput. It’s an adaptable foundation that allows your architecture to evolve without rewrites. It’s an operational safety net that turns data recovery from high-risk surgery into a deterministic replay. And it's a governor of truth that helps you distinguish business facts from raw noise.

If your system's source of truth could guarantee correctness and adapt with your business at any scale, what problems would you be free to solve next?

Frequently Asked Questions

Can you use PostgreSQL as an event store?

Yes, at low volume. PostgreSQL handles an append-only event table well until roughly one to two million events, at which point stream reads and projection rebuilds degrade sharply. Teams typically move to a purpose-built event store when replay time starts affecting deployments rather than when write throughput becomes a problem.

Can you use MongoDB for event sourcing?

Yes, with the same caveat. MongoDB's document model maps cleanly onto events and its write throughput is strong, but it offers no native support for the consistency guarantees event sourcing needs across concurrent writers to the same stream. That coordination becomes application code you write and maintain.

What is the best database for event sourcing?

There is no single answer, but the deciding factor is usually not raw speed. It's whether the store natively enforces consistency on a stream, supports replay without custom tooling, and lets you change your consistency model without a migration. General-purpose databases leave all three to you; purpose-built event stores handle them as infrastructure.

What's the difference between an event store and a regular database?

A regular database stores current state and overwrites the path that produced it. An event store keeps the full ordered sequence of changes and derives current state from it, so any previous state can be reconstructed. The practical difference shows up when you need to answer why a system reached a given state, not just what that state is.

Do you need a special database for event sourcing?

Not to start. You need one when the cost of working around a general-purpose database: custom concurrency handling, hand-rolled replay tooling, projection rebuild times measured in hours. This exceeds the cost of adopting a purpose-built one. That crossover tends to arrive between one and ten million events, depending on stream design.

Can you do event sourcing with SQL?

Yes. A SQL event store is usually a single append-only table with a stream identifier, a sequence number, and a serialized payload, plus a uniqueness constraint on the stream and sequence pair. It's a sound starting design. What it doesn't give you is efficient stream reads at volume or coordination across multiple application instances.