Non-transactional requests and their decision of which timestamp to use complicate our transaction model. These requests do not carry uncertainty intervals but still desire to provide single-key linearizability. As a result, they lead to complex interactions with the HLC clock in an attempt to provide the guarantee that non-transactional requests observe any change that was performed causally before them. Instead of assigning a timestamp at the client and using an uncertainty interval to ensure reads-your-writes, they delay the assignment of a timestamp to the server.

As discussed in #58349, this complication does not seem worthwhile. From a performance-perspective, non-transactional requests should not be any cheaper than a 1PC transaction. And since non-transactional requests cannot span ranges, we know that any non-transactional request can also be expressed as a 1PC transaction. We should explore eliminating non-transactional requests and replace them with 1PC transactions.

Epic CRDB-1514