Ok, I did. I actually read the whole series, including the postgres 2-phase commit I/O error case.
I don't see where it draws that conclusion at all.
The postgres post shows that even ACID databases have network error cases which can leave your client in an indeterminate state. Fair enough. However the solution for this is... to restart your client once the network's back up. All it needs to do is requery the DB to determine the truth.
Compare that to writing conflict resolution logic for all your data because there is no single source of truth. This is considerably more complicated.
The series actually ends up recommending "the right design for the right problem space." I am not making a general SQL vs. NoSQL argument here, but I think in this case they may have taken a more complicated approach than necessary.
I don't see where it draws that conclusion at all.
The postgres post shows that even ACID databases have network error cases which can leave your client in an indeterminate state. Fair enough. However the solution for this is... to restart your client once the network's back up. All it needs to do is requery the DB to determine the truth.
Compare that to writing conflict resolution logic for all your data because there is no single source of truth. This is considerably more complicated.
The series actually ends up recommending "the right design for the right problem space." I am not making a general SQL vs. NoSQL argument here, but I think in this case they may have taken a more complicated approach than necessary.