| 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. |