CQRS, command query responsibility segregation, splits an application's write model from its read model instead of using one schema for both. Commands, PlaceOrder, CancelSubscription, go through a write model focused on business rules and invariants; queries hit one or more read models built and optimized purely for how the UI actually needs the data. The split adds real infrastructure, so it earns its place on domains with complex business logic or wildly different read and write shapes, not on a basic CRUD form.
The core idea
A single database table is a compromise: it has to serve both validating a write against business rules and rendering data efficiently for ten different screens, and those needs pull in opposite directions. CQRS resolves the tension by accepting two models, a write side that enforces invariants and stays normalized, and one or more read sides that are denormalized, cached, or indexed however each query needs. The two are kept in sync by an event or a change-data-capture pipeline, usually asynchronously.
What changed in 2026
- CQRS-lite became common without full event sourcing — teams split read and write models across two tables or databases without adopting an append-only event log, getting most of the benefit at a fraction of the complexity.
- Read models increasingly live in purpose-built stores — a denormalized Postgres table for one screen, Elasticsearch for search, pgvector for semantic lookups, each read model shaped for exactly one access pattern.
- Change-data-capture tooling matured, Debezium and equivalents, making it far more reliable to keep read models in sync with the write model without hand-rolled dual writes.
- AI-assisted feature work increased read-model proliferation — as teams shipped more bespoke views faster, the read side of CQRS setups grew larger relative to the write side.
How it works
| Side |
Responsibility |
Typical shape |
| Command |
Validate business rules, mutate state |
Normalized, transactional, often the event-sourced aggregate |
| Query |
Serve reads, no business logic |
Denormalized, one shape per screen or use case |
| Sync mechanism |
Keep read models current |
Events, change-data-capture, or a scheduled projection job |
A command handler never reads from the query side, and a query handler never writes — that separation is the entire point, and it is what lets each side scale, cache, and evolve independently.
Common mistakes
Adopting full CQRS for a simple CRUD screen. If one table already serves reads and writes fine, the two-model split is pure overhead — reserve it for domains with real complexity or scale pressure.
Letting the read model drift out of sync silently. Without monitoring the projection pipeline's lag, a read model can serve stale data for hours before anyone notices — treat sync lag as a metric worth alerting on.
Putting business logic in the read model. Validation and invariants belong exclusively on the command side; a read model that also enforces rules creates two sources of truth for the same decision.
Assuming CQRS requires event sourcing. They pair well together, but plenty of production CQRS systems sync a denormalized read table from a normal relational write model with no event log at all.
FAQ
Do I need event sourcing to use CQRS?
No — see event sourcing explained in 2026 for how the two relate; many systems use CQRS with a conventional write database and no event log.
When is CQRS worth the complexity?
When read and write shapes genuinely diverge, a domain with complex business rules on write and many different, high-performance read views, or when reads and writes need to scale independently.
What keeps the read model in sync with the write model?
Usually an event published on write, or change-data-capture off the write database, consumed by a projection process that updates the read model asynchronously.
Can a read model use a completely different database?
Yes, and it often should — a search-optimized read model in Elasticsearch or a similarity-search read model in Postgres with pgvector alongside a transactional write database is a common pattern.
Where to go next
Read event sourcing explained in 2026 for the write-side pattern CQRS is most often paired with, design patterns explained in 2026 for the broader architectural vocabulary, and pgvector explained in 2026 for a concrete example of a specialized read-model store.