Active-active is when you don't have any replicas, you have just one data store and multiple 'engines' accessing it. So there is no replication, because there is nothing to replicate. So CockroachDB is definitively not active-active, despite their claims to the otherwise; what they call active-active is two-way synchronous replication, which is worse than asynchronous replication because of the latency and worse than Oracle RAC active-active because it's less fail-tolerant. In Oracle RAC your cluster is up and running even if just one engine is still alive, in CockroachDB approach when you lose majority of nodes the cluster goes down.
Obviously Oracle RAC active-active has it's own downsides, too, but it's another topic.
EDIT to expand: Think about a SQL transaction. In Oracle RAC it gets picked up by any of the nodes and is executed by this node. All the other nodes see updated data immediately. In CockroachDB the same transaction would need to be executed by each of the nodes separately plus the overhead of communication between the nodes.
You have a misconception about CockroachDB and YugabyteDB architecture. It is not 2-way replication. It writes to a Raft group. The transaction can be picked up by any node because the transaction intents are also replicated. The main difference with RAC is that the current version of a row is read/write on the Raft Leader, replicated to followers (that can be elected new leader). In RAC, the block with current version of a row is moved back and forth between the instance. That's possible only with reliable, short distance, dedicated network. Distributed SQL can scale out to multiple availability zones. Not RAC
> In Oracle RAC your cluster is up and running even if just one engine is still alive
So it's not consistent in the CAP Theorem sense. Comparing it with other databases that don't lose writes and don't have split brain issues makes no sense
Oracle RAC is a shared storage system, every database instances write to same datastore, so as long as a transaction is committed by one node, it'll be seen by other nodes.
Of course, the issue with all shared-storage systems is how much it costs to have a reliable and fast shared storage.
It is always consistent because it is a single storage database with multiple access points. It's not distributed data so CAP theorem doesn't even apply to it.
