MVC and CQRS are apples and hand grenades. MVC is about routing user actions from a view and returning data. CQRS is a data access pattern to avoid side effects in queries and provide a simple scaling solution. Part of the problem is that model is probably one of the most used words in patterns and not all of them are mutually exclusive.
MVC and CQRS can be used together or separately. The model from MVC is really a UI level representation of data structures, the physical data model need not be anything similar. It is generally best practice for MVC Models to call some other thing (like a service) to get/save data, in a CQRS world the model would be calling separate things for read/write actions. Where data is persisted is somewhat outside the concern of MVC, so long as the model knows how to access data and nothing else does.
CQRS is concerned with isolating all reads (Query) to only read and never write, and all writes/creates/updates (command) to only write. The model used to write should also be different than the model returned from a read, which in most normalized relational databases is almost self fulfilling. Furthermore the database or whatever is used for persistence doesn't need to be the same one for commands and queries. If the same web app is doing both reads and writes through the respective services, that is outside the scope of CQRS.