[AdrianRossouw]

Well, it's the opposite perception here.

"I've rarely seen - and its possible that this is selection bias - companies start with the other NoSQL options."

It seems like everyone starts with Mongo, because everyone starts with Mongo.

This means that you don't have the deluge of posts from people moving from other databases,

a) there are much fewer of them b) they chose them for solid technical reasons (not just because everyone does this)

So as for your perception that other NOSQL databases are "probably" more complicated, you should know that complexity is an objective measure. I think that mongo is definitely a lot more objectively complex than couchdb, and from what I have read around the subject, many of the other NoSQL databases.

What Mongo could well be is 'easier', which is relative. It seems like it's more familiar to certain programmers, which is kind of echoed by the fact that there's an incredibly popular object relational mapper (mongoose), that is being used with what is supposedly a non-relational database.

I use those terms in a very specific sense btw, which I documented here - http://daemon.co.za/2014/03/simple-and-easy-vocabulary-to-de...

It's from a very insightful presentation by the creator of the Clojure language, and I only wrote a summary because I got sick of trying to get people to watch an hour-long video before trying to discuss systems on this level.

[tracker1]

Mongoose adds a bit to the table. It actually adds schema validation, which mongo doesn't inherently have, and should be part of the application anyhow. I feel that's the biggest reason to use mongoose over the straight mongo driver in many cases.

I've used Mongo in a couple projects where it was a great fit. The scale wasn't huge, but having pre-shaped data for a mostly read scenario was great. I've found that it works really nicely for a lot of situations, and would definitely be a consideration.

I find that document databases work best when your data is read far more than written to, and when you can shape your data structures for simple key reads in most cases combined with indexed searches. I would consider the use of ElasticSearch or RethinkDB in most cases where you might look at MongoDB. It really depends on your needs here.

Riak and Couch offer other advantages, and like anything it really depends. Cassandra is another nice option for larger scalability, but everything has a cost.

Mongo is very reasonable, and to be honest, if you don't need more than a single server for your needs, it's really easy to get up and running quickly, and development tooling is decent enough, and the concepts are pretty easy to get up to speed with.

[nemothekid]

I can't speak for everyone, but to me MongoDB is far easier than any other NoSQL engine I've looking into. The reason why I said "probably" because I can't speak for every NoSQL database out there.

We had a 5 node cluster in Mongo that we moved to Cassandra last summer. While our experience with Cassandra is by and large much more performant and cost effective than MongoDB, getting setup with Cassandra was not as easy with MongoDB. With MongoDB you can literally start throwing data in your database, then add an index after the fact. With Cassandra we had to make sure our data was modeled correctly, and decide where we would denormalize. Riak from what I remember has a similar data model to Cassandra, and Redis isn't something you just "start up and go" (mainly because its an in memory store).

So I know for a fact that Cassandra, Riak, Dynamo, and Redis are far more complex than MongoDB. Cassandra even requires you run a "repair" command periodically, and that alone makes it more ops work than Cassandra. We can even throw HBase in there too as it requires Zookeeper nodes, Named Nodes, and all that Hadoop goodness.

Now none of these databases are hard to use, but compared to mongo, mongo is a cakewalk. You literally spin it up, throw json inside, and get json back. There is no query writing, and for most cases there is very little ops management. In most cases if a query is slow, you can fix that by adding an index, or moving to SSDs, only once you have exhausted these options do you really have to consider anything else.

FullContact also has a similar story : http://www.fullcontact.com/blog/mongo-to-cassandra-migration... tl;dr Mongo was great for getting the product up and iterating quickly, but then they moved once they thought they needed too. Its my opinion that its far easier to get started with MongoDB that it is to get started with Postgres/MySQL.

Lastly, damn the technical reasons why its so popular, Mongo/10Gen used be a huge marketing engine around ~1.6/8. They captured a lot of developer mindshare and I'd attribute that to why its so popular now as well. Wasn't much longer after that when they naysayers & those hurt by the initial hype came out of the woodwork and we got the now infamous "MongoDB is webscale" video.