Thank you for sharing your strategy for concurrent transactions. It&#x27;s a very interesting topic :)<p>I see however some possible pain points in this strategy. My main concerns are:<p>* This looks to me a lot like some poor (no pun intended) form of MVCC (<a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Multiversion_concurrency_control" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Multiversion_concurrency_contr...</a>). Basically, it supports only two &quot;V&quot;s, the &quot;on&quot; and &quot;off&quot;, while &quot;normal&quot; MVCC implementations support as many as required.<p>* Related to the above, I don&#x27;t see how you can support more than one overlapping tx with this strategy. Sure, I&#x27;ll keep tuned for the next post on this topic, but I fail to see how --without exclusive locking-- it could be done based on these principles.<p>* Every read seems like it needs to check the switch. I understand this might be expensive, specially if there is a concurrent modification in progress. Keys are co-located in the node, but they still require random access.<p>* It looks like even aborted transactions require writes to the database. And every transaction requires at least two writes (the write intent and its consolidation to the key). I don&#x27;t expect good performance here.<p>Please help me clarify these questions, specially if I&#x27;m missing something. Hope it helps anyway. Thanks!