CQRS Does Not Require Event Sourcing

Technical Insight

Common Advice

The common advice is that if you use CQRS, you should also use event sourcing. That advice is attractive because the two patterns are often mentioned together, and in event-sourced systems the separation between writing and reading state is sometimes very natural. But the association is not a requirement. CQRS separates the responsibilities or models used for commands from those used for queries. Event sourcing changes how state is persisted by treating events as the source of truth. They are related in some systems, but they are not the same architectural decision.

The standard guidance is that CQRS should be paired with event sourcing so that commands produce events and queries consume them. It is easy to see why teams reach for that combination. Event-driven systems often need to replay history, reconstruct state, and support audit trails. CQRS gives a natural place to decouple write-side intent from read-side projection. On paper, the pairing looks elegant and architecturally complete.

Why It Is Incomplete

That advice breaks down when the real need is much simpler. CQRS can be useful when read and write responsibilities have meaningfully different shapes, workloads, security needs, or evolution paths. In those cases, the benefit comes from separating the command model from the query model, not from making the system event-sourced. A conventional relational database can support that just fine. The problem is that the architecture often gets overbuilt because teams assume that the more famous pattern must be part of the solution. In many enterprise applications, that is not true. The system does not need an event log just because it needs a different shape for reads and writes.

Root Cause

The two patterns are frequently discussed together because event-sourced systems naturally benefit from separate command and query models. That association can make them appear to be a single architectural pattern when they are actually independent decisions with different trade-offs. CQRS is about separation of responsibility. Event sourcing is about persistence and state reconstruction. One is a design choice about how the application is structured. The other is a storage model about how state is represented. Treating them as inseparable makes teams reach for more complexity than the problem requires.

Better Approach

I would treat CQRS and event sourcing as separate architectural choices. Use CQRS when separating command and query responsibilities provides a meaningful benefit, and continue using conventional persistence when it is appropriate. That usually means keeping a relational model for the authoritative state, using a command-oriented write path where needed, and shaping read models separately for reporting, dashboards, or user-facing queries. I would introduce event sourcing only when the business or technical requirements justify event-based state reconstruction, such as strong auditability, historical state replay, or domain workflows where events are the meaningful source of truth.

I also think this keeps the design easier to reason about. A CQRS system with conventional persistence can still be clear, testable, and maintainable. It gives you a boundary between intent and query without forcing the team to build projections, replay logic, versioning strategy, and event evolution into the architecture from day one. That is not a small difference in a real delivery environment.

Trade-offs

CQRS with conventional persistence can provide useful separation without introducing event-sourcing complexity. The trade-off is that separate read and write models can still increase application complexity, especially when the team has not clearly defined why the separation exists. Event sourcing can provide strong historical and audit capabilities, but it requires additional design and operational considerations around projections, consistency, replay, versioning, and event evolution. Combining CQRS and event sourcing can be powerful, but it is not automatically the right choice. The cost of that combination is often paid in operational and modeling complexity long before the system realizes the benefits.

When Common Advice Is Correct

The common advice is still correct in some situations. Use CQRS when read and write responsibilities have sufficiently different models, workloads, security needs, or evolution paths. Add event sourcing only when retaining and replaying domain events as the source of truth provides a concrete business or architectural benefit. In other words, neither pattern is a default. Each should be chosen because it solves an actual problem, not because it is commonly paired with another pattern.

Key Takeaways

• CQRS and event sourcing are separate architectural patterns.
• CQRS does not require event sourcing.
• A CQRS application can use a conventional relational database.
• Event sourcing changes the persistence model, not simply the command/query structure.
• Combine CQRS with event sourcing only when the additional complexity is justified.
• Choose each pattern based on the problem it solves, not because they are commonly mentioned together.