[chrisfosterelli]

MongoDB still has an awful reputation on Hacker News but I really appreciate the take from "Why RethinkDB Failed" [0]:

> People wanted RethinkDB to be fast on workloads they actually tried, rather than “real world” workloads we suggested. For example, they’d write quick scripts to measure how long it takes to insert ten thousand documents without ever reading them back. MongoDB mastered these workloads brilliantly, while we fought the losing battle of educating the market.

> almost everyone was asking “how is RethinkDB different from MongoDB?” We worked hard to explain why correctness, simplicity, and consistency are important, but ultimately these weren’t the metrics of goodness that mattered to most users.

> But over time I learned to appreciate the wisdom of the crowds. MongoDB turned regular developers into heroes when people needed it, not years after the fact. It made data storage fast, and let people ship products quickly. And over time, MongoDB grew up. One by one, they fixed the issues with the architecture, and now it is an excellent product. It may not be as beautiful as we would have wanted, but it does the job, and it does it well.

In my mind Mongo is a database that had great developer experience, excellent marketing, and some seriously bad technical gotchas. But marketing drove momentum long enough to cover bills, grab the market, and address most of the gotchas, so now it's a decent DB.

[0]: https://www.defmacro.org/2017/01/18/why-rethinkdb-failed.htm...

[kvn_95]

It also helps that the creator of the default storage engine (WiredTiger) are Keith Bostic of BerkeleyDB fame [0] and Michael Cahill, whose PhD thesis on serializable snapshot isolation [1] formed the basis of Postgres concurrency control [2]. Notably, both of them still work for MongoDB.

[0] https://en.wikipedia.org/wiki/Keith_Bostic

[1] https://dl.acm.org/doi/10.1145/1376616.1376690

[2] https://wiki.postgresql.org/wiki/SSI

[jaysonqpt]

I think MongoDB 3.6 is when it became a "decent" DB.

Azure CosmosDB provides protocol level for MongoDB 3.6. This offers developers a neat way of using the power of distributed CosmosDB without sacrificing cloud portability.

[stennie]

Cosmos' API is an emulation of MongoDB which differs in features, compatibility, and implementation from an actual MongoDB deployment. Cosmos' suggestion of API version support (eg 3.6) is referring to the MongoDB wire protocol rather than the full MongoDB server feature set for that version. There are also some inherent differences, such as Cosmos' Request Units (RUs) which need to be considered for capacity planning and costs: https://docs.microsoft.com/en-us/azure/cosmos-db/request-uni....

Those differences may be fine for some use cases, but definitely compromise portability if you want to run or test the same application with a database deployment on GCP, AWS, or your own infrastructure. The lowest common denominator is based on Cosmos DB's underlying limits and features (not a MongoDB server feature set): https://docs.microsoft.com/en-us/azure/cosmos-db/concepts-li....