[uptownJimmy]

MongoDB is notorious for losing data. That alone is a deal-killer, and reason enough to stay away.

The slightly more complicated thing: it isn't even necessary for us to reinvent the database wheel, except for the fact that SQL is hard. Lots of people spend their entire careers avoiding SQL like the plague, which is okay because they have an SQL-ninja down the hall handing them queries to plug into their code. But for a lot of open-source weirdos, that ain't happening, because there's no SQL-ninja down the hall, just more JavaScript hipsters and Rails hippies. So Monongo!

Problem is, it ain't cool to lose your client's data. It's a career disaster. NoSQL is gonna have to get a LOT more robust before most professionals will accept it as a swap-in for SQL.

Lastly, and this is kinda the heart of it for me, is this: data is almost always inherently relational. And we simply haven't come up with anything better than SQL to manage this relationality. Maybe we will, I don't know. Meanwhile, it doesn't take a Bearded Old Programmer to see that there's something a little too bubbly about Mongo and its NoSQL kin.

[polysaturate]

That is a perfect explanation, that I was looking to make.

Not to say mongoDB and noSQl don't have their place, but I don't think that place is, all of your application's data.

[nathan-muir]

Thanks for your reply.

I was asking to see if there was any crucial evaluation I had missed putting MongoDB into production.

Below are a few replies to the points you raised:

---------

Data Loss:

Agreed this is a big cloud over the head of MongoDB -

Is it still notorious for this in recent times? Hopefully DBA's for Mongo now have more experience, and the software has matured enough that this isn't a common problem. - or more than it would be for any database.

Even then, you can only fall so far if you take regular backups, and have a fail-over & data recovery plan.

--------

"SQL is hard":

I get your point - a lot of people don't like or understand SQL. However, you seem to lump them with everyone who would appreciate an alternative interface.

Personally, I quite like SQL - some would call me an SQL-ninja. However, I don't think we should be limited to SQL as the one-true-way for accessing data.

Sometimes these new "NoSQL" interface allows new technologies to emerge. For example, the reason MongoDB is being used with Meteor is two-fold:

1. Minimongo - A wholly javascript based mongo query engine. It would be a much harder engineering problem to build a similar tool for SQL / PostgreSQL. 2. Logical Replication - A Meteor instance is effectively a logical replica of the Mongo Database - only for "live" queries, which it interprets using (1)

(1) Means that queries/ their surrounding code can be isomorphic (same on client and server). To replicate this for SQL would be a huge engineering challenge. How would you even replicate complex joins etc?

(2) Logical replication was only made available in PostgreSQL 9.4 - but without a pluggable query interpreter [even for join-less queries], it still wouldn't work.

----------

Relational Data:

Agreed, that data itself is best decomposed into fully-normalised form (Even up to 6th Normal form if you like temporal data). This allows for single-location, conflict-free and consistent updates/inserts/deletes.

But data usage is inherently document based - and the generation of those documents from fully normalised data, on huge data sets with complex relations, is a massive problem!

Until we have better tools for managing documents made of relational data - eg. PostgreSQL materialised views, but update only invalidated rows, - there will still be a drive to store data (& maintain) in the format that it is read.