@ajm @branmin - I generally believe that if you really understand something you can express it simply. In fact I think that half of technical language was created just to make specialists seem smarter than everyone else, when in reality most people can understand most topics if minimize the special vocabulary. I’m not trying to criticize, and of course you are trying to discuss a detailed topic, but as branmin expressed, I think in these public forums we all gain when we help each other understand our specialized areas of knowledge.
…Mongo because of the document model. It is easy to start with and that has paid dividends as a strategy, but I suspect in 3-5 generations products built off of it will find themselves in tough positions with document versioning and exponential maintenance complexity growth. You can still have structured data in k/v or wide column stores
So, I have to admit I don’t understand your arguments - maybe you overestimated my technical knowledge 
One area of confusion that I have is that MDB is not a distributed database. You can shard collections, but most current data stores, including most Sql databases, have a way of horizontally scaling across multiple machines. True distributed data stores are blockchain implementations and other types of distributed ledgers, and that technology is at least 5 years away, I estimate, from broad use for data storage - even then it will be for very specialized cases.
Secondly you talk about the difficulties of document versioning. I struggle to understand what you mean. To explain my understanding, in document oriented databases such as Mongo, the word “document” is an analogy. Instead of strict tables, columns, and rows like you have in sql, “document-oriented” data stores have collections, and each “document” inside it is analogous to a row in sql.
Mongo is also quite structured in practice - most collections in Mongo data designs have common data fields, the way that tables in sql have columns. The difference is that Mongo collections are flexible - individual documents can have different fields. In practice, in a well-designed Mongo database all documents in a collection have a subset of the fields supported by that collection. This is a very good fit with object-oriented design, by the way.
So, since documents aren’t really documents, but actually a type of flexible row, documents aren’t versioned in Mongo any more than sql rows are versioned. It is possible to keep history of a database - there are many different data patterns that help solve this very difficult problem - but most MongoDB databases won’t require it just as most Sql databases today don’t require it.
I know there are a lot of passionate Postgres users - I personally liked it 20 years ago when it was a hot new thing. But I really think we are talking about an order of magnitude difference between it and various NoSql data stores.
I agree that there are different types of NoSql - there are lots of specific cases for key-value, wide column, etc data stores. But I do believe document oriented databases are clearly winning as the general purpose database, because they work well for both structured and unstructured use cases.
Mongo is winning as the document oriented database, and this is likely to stand for the next 20 years. Don’t forget that Mongo won’t stand still - they already implemented the WiredTiger engine which allows all sorts of different flexible representations of your data.
You can expect that in a few years you will find kv, wide column, and blockchain all under the Mongo umbrella, and maybe all within the latest WiredTiger engine. That’s my prediction - you can call me on it in a few years.
By the way, I just found out I’ll be representing my bank at the upcoming MongoDB World conference, so I’ll ask the Mongo guys this question at the roundtable