I, well, one my companies, have been using mongo for a while without any problems. I cannot comment about is reliability but as a business tool, in the niche area we operate, it served us well. I've got nothing against relation databases but there are not a solution to every single problem. Heck, why not decide first if you can use flat files? Do you really need to query and join. Not all problems require that sort of thing.
> I, well, one my companies, have been using mongo for a while without any problems. I cannot comment about is reliability but as a business tool, in the niche area we operate, it served us well.
The issues I listed provably exist. That you haven't run into them yet doesn't change that - and quite likely, you might not even know whether you've run into it.
Losing data or having your database open to the wide internet, for example, are two scenarios that you will likely not be aware of unless you explicitly test for them.
> I've got nothing against relation databases but there are not a solution to every single problem.
And if you'd read my post carefully, you would've seen that I make no such claim. They do solve many problems, however.
> Heck, why not decide first if you can use flat files?
Flat files are rarely the correct solution. Race conditions ahoy!
> Do you really need to query and join. Not all problems require that sort of thing.
Many do. And even if they don't, MongoDB is still not the right choice.
Postgres 9.4 even has `jsonb` and GIN indexes, which in a lot of ways provides nicer schemaless storage than some of the NoSQL databases provide. You're also free to mix in traditional relational tables (since `jsonb` is a data type like any other), or even efficiently join two tables based on a JSON containment operator. I haven't looked in to it _too_deeply, but what I've seen so far looks really neat.
If nothing else psql has a nice tabular output. Sometimes I go out of my way to import something into a local pg instance just so I can format things using psql.
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.
