Whoa, this is a worrisome attitude. 1. The bugs that MongoDB historically suffers from are those that are unlikely to occur for most people, but when they do c

Whoa, this is a worrisome attitude. 1. The bugs that MongoDB historically suffers from are those that are unlikely to occur for most people, but when they do cause the most suffering. This is a combination of them being incredibly hard to replicate, but more insidiously that the system keeps working, it just has a small data corruption. This can obviously lead to huge problems down the line. The conclusion is firstly that just because you haven't seen a problem doesn't mean there isn't one, but also just because there isn't a big problem for you doesn't mean there won't be one in the future. 2. Databases have some of the most demanding testing around, due to the important requirements placed on them. There's a really good talk floating around from a guy at FoundationDB. The sorts of bugs that keep cropping up in MongoDB are the sorts of bugs that level of testing would find, which is a very bad smell. Thus, one should only resort to MongoDB if no other solution is reasonable. But in reality, for most tasks something like Postgres (with JSON additions) or CouchDB etc is equally suitable and easy to use. This means that most new users of MongoDB can actually afford to use a better/less buggy database, they just choose not to. 3. Flat files are generally a silly idea mostly because of the additional tooling that databases give you. ORM systems make using a database much, much easier than using flat files, and the databases usually allow easy analytics. They also typically give better error messages, better performance, better extensibility etc. If it comes time to move your data into the cloud, you'll have a much easier time of it if you use a database etc. It's a win-win in almost every case.