One relevant point here is that it's relatively easy to merge two branches of changes for a simple (key/value) data model, but harder to merge changes to relati

One relevant point here is that it's relatively easy to merge two branches of changes for a simple (key/value) data model, but harder to merge changes to relational data where there are additional constraints (like foreign keys) which must be preserved. That said, just because it's easy to merge key/value data, doesn't mean that the results of the merge are necessarily going to be correct. The constraints still exist, they're just not explicit in the data model, meaning that when your network partition gets joined up again and it magically merges all those changes at the key-value level, you may be ending up with data that's broken in subtle, difficult-to-track-down ways because other implicit constraints weren't respected by the merge. So, merging changes in a way that respects constraints which apply to that data, is a hard problem in general. Key/value stores, with their less-structured data model, sweep that problem under the carpet somewhat in order to make things easier in distributed settings. Relational databases suffer from trying to address the problem more fully.