A team proposes CQRS for a CRUD admin panel because reads are slow. Is that the right call?

Why not CQRS here

"Reads are slow" is a symptom with many causes, and CQRS addresses only one of them: the read and write models having genuinely different optimal shapes. On a CRUD admin panel that is unlikely — the screens usually mirror the entities.

Far more probable causes, all cheaper to fix:

• A missing or wrong index, which the query plan will show in minutes.
• Stale statistics producing a bad plan.
• N+1 queries from an ORM, which is the single most common cause of a slow admin page.
• SELECT * pulling large columns nobody displays.
• Unbounded result sets — no pagination, so the page renders ten thousand rows.
• Aggregations computed per request that could be precomputed.

Each is an afternoon. CQRS is an architecture with a permanent maintenance obligation.

What CQRS would actually cost here

Two models to keep in step. A projection that must be idempotent, ordering-aware, rebuildable and monitored for lag. Eventual consistency visible to the user — an admin who edits a record and does not immediately see the change, which on an admin panel is a functional regression rather than an acceptable trade. And a new class of bug: the projection silently stalling while reads succeed and data is wrong.

When CQRS is right

When read and write shapes genuinely diverge: vastly more reads than writes, reads needing shapes the write model cannot serve without expensive joins, several different read shapes over the same data, or a read workload whose scaling profile differs sharply from the write workload.

Note it does not require event sourcing — that is a separate decision, and coupling them is a common way to acquire two large commitments while needing neither.

The intermediate options

Before CQRS, in order: fix the query; add a materialised view for the expensive aggregate (most of the benefit, a fraction of the complexity, and the database maintains it); add a read replica if the issue is contention rather than query shape; add a cache for genuinely hot reads.

What a strong answer adds

Asking to see the query plan and the p95 latency by endpoint before agreeing to any architecture. "Reads are slow" without a measurement is not a requirement, and the number of architectures adopted to solve a missing index is not small.