CQRS is two models, not two databases

The pattern gets introduced alongside event sourcing, separate stores and eventual consistency, which makes it look like an architecture. The idea underneath is smaller: the shape that is good for writing is rarely the shape that is good for reading.

// write model: invariants, one aggregate, no joins
$order->addLine($sku, $quantity);
$order->applyDiscount($rule);
$this->orders->save($order);

// read model: one flat query, no objects, no rules
$rows = $this->db->select(
    'SELECT o.id, o.total, c.name FROM order_summary o JOIN ...'
);

Two models against the same tables is the version most applications should stop at, and it costs nothing but the discipline of not reusing the write model in a listing screen. Separate stores, projections and the consistency lag that comes with them are a later step, taken when reads and writes genuinely need to scale apart. Starting at the far end is how the pattern earned its reputation.