Yep, and even in scaling out [1]. The main problem of MongoDB is that they tried to make a general purpose NoSQL database. The thing is that this is the area t

Yep, and even in scaling out [1]. The main problem of MongoDB is that they tried to make a general purpose NoSQL database. The thing is that this is the area that RDBMS are trying to solve from the beginning. There are decades of research and solving problems. When you're using MongoDB you're essentially going back in evolution to 60-70s when hierarchical databases were used[2] and you're running into problems that were already addressed in RDBMS decades ago (for example locking vs MVCC[3]). The original NoSQL was created to solve very specific type of data storage (originally in terabytes+ range, that you can process using highly parallelizeable map&reduce operations) and of course you're trading something in return (most of the time database consistency). There's no silver bullet solution. The worst reason for picking MongoDB database though is because of storing data as JSON. Many companies that do that (including mine) believe DBAs just are slowing them down, so by picking a schema-less database they can release new features faster. They don't realize that they will need to still enforce schema in their applications and that is actually much harder and can become very ugly. Otherwise the data will resemble a pig sty. Personally I'm not too enthusiastic about JSON in PostgreSQL, but I guess it gives flexibility as of what data schema should be enforced and what not. And there's always an option to migrate to use schema. [1] http://www.datastax.com/wp-content/uploads/2013/02/WP-Benchmarking-Top-NoSQL-Databases.pdf http://www.datastax.com/wp-content/uploads/2013/02/WP-Benchm... [2] https://en.wikipedia.org/wiki/Hierarchical_database_model https://en.wikipedia.org/wiki/Hierarchical_database_model [3] https://en.wikipedia.org/wiki/Multiversion_concurrency_control https://en.wikipedia.org/wiki/Multiversion_concurrency_contr...