You’re right that CockroachDB uses synchronous replication. More specifically, for writes, CockroachDB uses a consensus protocol called Raft to guarantee that, for a given piece of data, a majority of replicas of that data (2 of 3, by default) agree before the change is committed. Since each replica is always on a different node (for resiliency to failure), network latency is a factor. However, there are various SQL and operational techniques to optimize performance. You might be interested in our Performance Tuning tutorial for more insights along those lines.
Replication, by the way, has nothing to do with which node received the
cockroach init request to initialize the cluster. For each piece of data, rather, there is a replica “leader” and replica “followers”. That perf tuning tutorial explains this more. The Replication Layer page in our architecture docs might also be helpful.
To address your use case, there is currently no way to configure CockroachDB to be “eventually consistent” like some NoSQL databases. It’s not designed for that. Instead, you have two options, I think. You can optimize the performance of reads and writes as described in that perf tuning tutorial and retain the fault tolerance benefits of CockroachDB. Or you can disable replication entirely by running this command:
cockroach zone set .default --insecure --disable-replication --host=<address of any node>
cockroach zone set .default --certs-dir=<path to certs directory> --disable-replication --host=<address of any node>
It’s important to note that, if you disable replication, and have only 1 copy of each piece of data, you completely lose the fault tolerance benefits of CockroachDB. For example, in this case, if the node containing data for a specific table goes down, that data becomes completely unavailable, whereas in a replicated scenario, as long as a majority of the nodes with that table’s data are online, all is well.
I hope this helps. Please let me know if you have follow-up questions.