I think it all comes down to what definition is of solving a problem.

What Mongo did is implementing these features just well enough so they can put checkpoint in their marketing brochures.

When you actually start using it you learn that most of it is either performing slow, does not work correctly or once in a while corrupts your data.

Yes they hit these points hard, but only from marketing point of view. They are now universally hated by ops and developers because these people now have to deal with fallout.

RethinkDB actually is an example that database is something that's not good as a base for a startup[1], and the Open Source approach (like PostgrSQL) is more suitable.

MongoDB is example that you can base a startup on a database technology and succeed, if you can sleep well at night that your product can cause people to lose data.

[1] The reason RethinkDB failed was because they refused to provide half solutions like MongoDB, everyone expects startup to start making money, but building a reliable databases is not something that's easy and can't be done quickly.

> Yes they hit these points hard, but only from marketing point of view

MongoDB serviced one of my projects for 5 years without a single hitch. It did everything I wanted it to do, it did it well, it did it exactly as advertised (no more, no less), and it did it right when I needed it. It never stopped improving during those years, massively in some aspects. The company behind it only grew stronger during those years, and along with it, so did my confidence that my project wouldn't need to undergo re-engineering further down the line.

Seriously, as a professional software developer, what more do you want.

My experience too, 6 years. Never been a fanboy, but don't understand the hate either. MongoDB never surprised me, the tradeoffs were known in advance (at least the ones that mattered to me).

Based on my experience, your use case was simple enough that any database would do just fine.

Our use case was not simple, but MongoDB made it simple to implement. We used pretty much every feature of MongoDB. Any other database could have been coerced to do what we needed, of course, but with greatly varying degrees of extra complexity or overhead.

Please elaborate on how your use case was not simple, and how your data was not relational in the slightest.

Because of the term 'NoSQL' people (programmers) assumed they could throw all the information all those neckbeards are whining about overboard. Because NoSQL, people don't seem to treat it like a database and just toss data in it and run queries in the most insane manner possible. Just ignore the fact that your code makes it so that every single query is doing a full tablescan! That doesn't matter on NoSQL right? For a long time, case insensitive queries on a field were done (and recommended) using a regexp...

MongoDBs clients are much more simple to use than that of RethinkDB. Imho that was the number one reason it didn’t gain traction.

I'm curious what you mean by this. We use a combination of RethinkDB + Deepstream at work and it's amazing to work with with really simple querying language. I might very well be missing something, though, as I'm not the main developer so not too deep into it.

For one is the extra database handle and run I have to use every time, instead of the commands being methods to the db handle object. The repetition of males code more verbose.

Secondly, it’s the ReQL. It’s not native but not JSON based either. A weird hybrid mix.

But it’s only my personal opinion based on my taste.

And there are no bad reviews of Rethinkdb because nobody used it for real

There was at least one review from someone who switched from RethinkDB to Postgres, which includes a lot of pain points and the line:

> A RethinkDB employee told me he thought I was their biggest user in terms of how hard I was pushing RethinkDB.

http://blog.sagemath.com/2017/02/09/rethinkdb-vs-postgres.ht...