Hi, thanks for the reply!<p>I will read the more detailed document. It would probably make more sense to me.<p>From the description of MVCC that you say, it looks like you&#x27;re storing the whole replicated state machine that you have via the Raft protocol. If txs are assigned such a timestamp, I agree that could operate as a full MVCC system. Good.<p>Regarding the overlapping txs, it makes sense once you say you&#x27;re aborting txs. Without that, it sounded really difficult to achieve without locking.<p>When you say reads only check the switch if there is a write intent, where is exactly that &quot;switch&quot;? I understood it&#x27;s not with the key, but rather at some other random location. If that&#x27;s the case, I insist that you require two reads: one for the key, the other one for the switch. Os is the switch co-located with every key?<p>Regarding the aborted txs, I can&#x27;t argue without numbers, but I&#x27;d like to see those. I mean: you may abort txs voluntarily (I want to ROLLBACK) or involuntary (there&#x27;s a concurrent conflict). That may or may not be a high number. But all of those would be written to disk, so it might become a high price.