Reads from CockroachDB go through a lease holder for the piece of data being read without needing confirmation from any replicas about consistency, so there is no overhead from replication. But read latency can be affected by writes on the data (conflicts), because it is fundamentally a consistent system (serializable). This is not tunable.
Thanks, that makes sense (and provides good context for the article). So for a cluster spanning multiple regions, one region can support low-latency reads for a given range, but reads in any other region will have to go cross-region to the leaseholder. Being able to move the leaseholder around to optimize read latency makes a lot of sense.
It would also be useful to me, in some cases, to be able to perform a read-only query in an "inconsistent" mode to avoid that cross-region latency, at the expense of potentially receiving stale data.
