It's just as desirable as with a simple database since it avoids certain anomalies (write skew). For many operations it's strong enough, but it adds the risk that you run into problematic anomalies you did not anticipate.

> In a write skew anomaly, two transactions (T1 and T2) concurrently read an overlapping data set (e.g. values V1 and V2), concurrently make disjoint updates (e.g. T1 updates V1, T2 updates V2), and finally concurrently commit, neither having seen the update performed by the other. Were the system serializable, such an anomaly would be impossible, as either T1 or T2 would have to occur “first”, and be visible to the other. In contrast, snapshot isolation permits write skew anomalies.

FoundationDB has a workaround, but I don't know how well that works in practice.

> In TiDB, you can use SELECT … FOR UPDATE statement to avoid write skew anomaly. In this case, TiDB will use locks to serialize writes together with MVCC to gain some of the performance gains and still support the stronger “serializability” level of isolation.

Serializability is more expensive of course, since the database needs to track what was read and not only what was modified. It is possible to achieve this in a distributed database, FoundationDB is one example that supports it.

https://tikv.org/deep-dive/distributed-transaction/isolation...