While CQRS can certainly be used for that, what it was developed for is not necessarily differing audiences with different usage requirements (read vs. write), but rather for scaling of the load.
By separating the read/query capabilities from write/command capabilities, it enables the underlying architecture a large amount of flexibility.
Ultimately this flexibility allows for two separate parallel implementations, one optimized for writing/update and the other optimized for reading/query.
The write path may be implemented using a relational store as normalized data is often very good for transactional updates.
Whereas the read path may use a denormalized (relational or non-relational) store because by pre-expanding the joins (thru denormalization) of heavily used queries, the queries can be simpler and run faster.
Event sourcing builds on that model, using an append-only log-style database of command events as the primary persistence mechanism. There may still be an normalized write store, but with ES, this can fail and be rebuilt using just the easy-to-persist events.
The interface separation encouraged by CQRS is useful if you need to go down the path of dual purpose-optimized parallel implementations for scale.
However, this is fairly complex stuff. The parallel implementations need to be synchronized with each other, and atomically as observed by readers and writers, unless you have some evidence to believe that your application performs stably when seeing temporarily inconsistent state. This means that as the synchronization mechanism is updating the denormalized store for any given update to the write side, that it ought to show query result consumers only results that include whole denormalized updates, and not partial, in progress updates.
In theory, you could separate the interfaces and yet not immediately add the complexity of the dual linked-but-separate implementations.
However, to truly separate query from commands, the commands need to be submit-only with pretty much no response from the server. Thus, in CQRS often we find clients issuing the primary key for a newly submitted entity, rather than the server. This adds a complexity even without using the dual parallel, linked data store implementations.
It would be difficult to guarantee you'd held the interfaces to the CQRS model if you are only using a single shared store as I believe there would be constant temptation to return values from a command unless a high degree of rigor is applied.
Some of the complexity involved is pushed back into the client who not only needs to provide primary keys for new entities, but also has to essentially wait for asynchronous changes to read the results of their own updates. All of this adds up to complexity that requires some not necessarily off-the-shelf available solutions.
