In short, the strategy was to develop a brand instead of code. It is nothing wrong to have a brand when you already have a superior design or innovative techno

In short, the strategy was to develop a brand instead of code. It is nothing wrong to have a brand when you already have a superior design or innovative technology, not the other way around. One of such manipulations were so-called benchmarks when in a mode in which the control returns to a caller function before an I/O operation is finished, successfully or not, without any error checking, which has to be done by calling a separate function explicitly. Basically, what did they measured was the performance of writing into a memory buffers. There was later some nonsense about default mode of operation, and when you really need your data consistent you should turn on a synchronous mode. The story of table-level write locks is less dramatic.) But the stories of "customer satisfaction", "increased productivity" (never to see an error) "features to jump-start the development" (by ignoring how your data is stored) were all over the site and paid content mills like techcrunch. In case there are questions about design here is the link: http://hackingdistributed.com/2013/01/29/mongo-ft/ http://hackingdistributed.com/2013/01/29/mongo-ft/ Keep in mind that this very crap is now "valued" at a sum compared to a budget of small country. In case you don't get it, the design of a fault-tolerant storage engine is a much harder problem. Serious systems, such as Informix at its time, resorted to write data in a chunks they call "pages" on so-called raw-devices (without any buffering by OS or hardware). They had page-level instead of row-level locking, and in case of failure they knew which pages were written and which not, so they could rollback the unfinished transactions. btw, they used the same pages for shared memory operations. This was a technology IBM brought for a billion dollars back in 2000. Compared to that MongoDB is just a Herbalife or any other scam.