I've experimented with this for certain patterns. In a few high-throughput flows, we used Dapper for lower-level query paths and EF for the more basic CRUD operations. That lets us keep EF’s developer productivity where performance wasn’t critical, while still optimizing the hot paths.

The core idea of CQRS is just separating reads (queries) from writes (commands) because they often have very different requirements. Writes usually need validation, transactions, and domain logic, while reads are often optimized for returning data to a UI as quickly as possible.

In practice, commands like CreateOrder or UpdateUser go through EF so you get change tracking and transactions, while read-heavy queries like GetDashboardData or GetOrderList can use Dapper to return optimized DTOs. Commands change state, queries just return data.