I don't disagree that oracle has excellent materialized view support, but triggers and other strategies can go a long way also, I think Dan Chak did a really nice chapter on this in his book enterprise rails, that is also available online for free at http://dan.chak.org/enterprise-rails/chapter-12-materialized...

I don't think riak came out looking too bad, was more documentation than anything.

https://aphyr.com/posts/282-call-me-maybe-postgres Also seemed solid

PostgreSQL was running only on a single machine i.e not clustered.

It is irrelevant in this discussion.

To be fair, most people who think they need a "big data" solution would do just fine with a Postgres single instance install.

There is far more aspects to big data than just how much data you store.

But regardless you completely missed the point. PostgreSQL was tested as a single instance. Everything else clustered. It's apples and oranges. The clustering part is the hard part here.

I didn't miss the point - I totally get it.

My point was simply to remind people that over complicating your situation and going for a "big data" store is usually a mistake when there's something that will keep your data safe when it isn't as big as you assume it's going to be.

You point to data (not really, no sources) You ignore alcohol usage entirely. You generalize the behavior of all prosecutors, without data again. And you seem think you are not naive and that in some way the system is "working"...

System works to what end ?

When a partition happens, you cannot communicate, you can choose to be available, or consistent.

If you choose to be available, for all operations at all disconnected sites, you may need to resolve conflicts in some fashion when or if the partition resolves.

If you choose to be consistent, you may need to deny operations to some portion of sites or for some portion of operations.

I find the ATM example to be very useful, I also try to whenever possible understand the system in terms of ledgers and accounting...they have been solving these problems also for a long time.

The formal definitions are very useful, and I would argue have unfortunately been lost in the noise. People are often trying to understand and compare many different and sometimes quickly evolving technologies, and these working definitions and misinterpretations seem to be largely related to misunderstandings or in some cases fit to the terminology of a specific vendor (which can be very confusing!)

It is also very useful to test your use cases and what you can tolerate in terms of consistency, latency, and availability with specific implementations.

I think a lot of the problem is that marketing material and documentation have collided in a similar fashion to reporting and advertising.

The unfortunate message seems to be: buyer beware

I think a similar thing has happened probably many times before, relational databases for instance and isolation levels are rarely discussed in terms of the formal definitions and much more often the vendor specific definitions.

My maybe much weaker message/ take away would be: define the terms that may be ambiguous so that you can get to the real fun of the ideas !

Couchbase conflict resolution is really basic, assuming you mean distributed in a wan context (eg xdcr). Riak would represent the state of the art in this respect (random internet endorsement, I'm not affiliated with anything, just a user who has worked with both systems).

Our XDCR doesn't have quite the power of our mobile sync conflict management, but I'd wager to say what we do for mobile is unbeatable as far as delivering unsurprising behavior for offline / p2p applications.

Perhaps the author was aware, but found it unacceptable that clients could choose their own sanity ?