I have to agree - if I had the choice to make again, I wouldn't have chosen MongoDB. It is a fundamentally broken product by design. For example, for their sh

I have to agree - if I had the choice to make again, I wouldn't have chosen MongoDB. It is a fundamentally broken product by design. For example, for their sharding setup they require three separate servers to host shard config data. The idea is to have high availability of that data should one of those config servers go away. However, by design, losing a single config server can cause multiple shard masters to die, requiring a manual restart. How they die and when is random, determined by where in a block migration a server is. How is this high availability? All three config servers must be running at all times without interruption for your cluster to be stable. Their roadmap to deal with this issue is sometime next year. One month not too long ago, my company found 90% of the bugs listed in their bug tracker for a specific release of MongoDB - many of which would have been found with a basic unit testing suite and some minor load testing. We were effectively performing QA functions for 10gen in our production environment. I've gone through nine releases of their PHP driver to deal with broken Data Center Awareness and none of them have worked - DCA still eludes them two years later. We have to do an OS level hack to make this work, that breaks other HA functions. Finally, their mmap design means that memory use is extremely inefficient - on a box with 256GB of memory, with a database that is only 100GB in size, it still hits disk on db reads because they offload memory management to the OS. Any other enterprise-level DB would preload the entire dataset in memory if there's room, but not MongoDB. It really is terrible.