This is getting close to being a philosophical discussion.
If a tree falls in the forest and no one hear it, did it make a sound?
If a codebase has split commands and queries but both sides refer to the same data store, is it CQRS?
Abstractly, I'm going to say yes to both questions. A sound is defined by a wave, not by its perception. CQRS is defined by having separate commands and queries (hence the name); having separate data stores is usually the ultimate goal and justification for doing CQRS but it's not inherently part of the definition.
In a past project I've worked on, we weren't sure what the performance was going to be like, as we had no concrete numbers on eventual adoption rate. Therefore, we decided to pre-emptively implement CQRS in the codebase, but to only use one database.
The benefit here is that we could save on DB server running costs for as long as there was no performance issue; and when such an issue presented we would not need to change the codebase, only one of the two connectionstrings in the config (which up until then had contained the same value.
From the POV of the developer, they are building a CQRS-oriented codebase. Whether or not the physical data stores are separate is irrelevant for the developer, as they have to write their code to account for them being separated anyway. Therefore, there is no meaningful benefit from defining CQRS based on the actual data storage devices.
he is using separate objects for saving data with POST operations than the ones used to retrieve data with GET operations
That is not CQRS though. Whether or not your reuse your API model across several endpoints has no bearing on whether you're doing CQRS.
Separating your models is one of those things that sometimes occurs when you're also doing CQRS, but in and of itself it does not fall under the umbrella of "doing CQRS".
My first impression on CQRS is that the shape of the data at rest is different for reading and writing
REST promotes reuse of the same API model across its endpoints. That's not a hard and fast rule (e.g. in cases where some fields cannot be updated after initial creation, you'd have a different update model); but in either case it has no bearing on whether you're doing CQRS.
What matters for CQRS is that a particular endpoint only reads or writes, it does not do both. For example, you should not have an endpoint which updates a value and then returns the updated version of the object.
Note that I'm excluding return values which act as confirmations that the write action succeeded. That's perfectly fine. I'm focusing on return values which contain the same data object that your were also writing to.
Just for completeness' sake, the CQRS split needs to persist all the way down to the persistence storage, otherwise there's no point.