- Never use a database because 'everybody else does', do your own research as to the advantages and drawbacks of a particular database.
I posted on the reddit thread to this. I'm an old crusty unix engineer. I've been around large "web scale" systems for over a decade. Whenever any vendor comes to me and says they have some magic bullet that can make their thing perform at X times anything else, I want to know what the cost is. TimesTen, a product now owned by Google, is an in memory database. It's not the first, but it is one of the better ones out there, and it's claim to fame is that its Ten Times Faster than Oracle, hence the name. The catch? It's an in-memory database. It checkpoints to disk at intervals, rather than after every transaction. If you want to be really sure you don't lose data, you need a synchronous cluster, in which case you lower performance because you're waiting for the ack from the remote node over the network. At the end of the day, you're bound by I/O constraints. How quickly can you write the data to something persistent, whats the latency on that operation, can an operation be grouped and rolled back, is it ACID compliant, etc etc etc. When people tell me that they have "designed" their app to be tolerant of data loss, I ask them to prove it, and they can't. There's always some edge case where, if their mongoDB cluster lost some bit of data, it could hose a whole bunch of important things. I was dubious of MongoDB when I first saw it used in a bunch of projects I was interested in. I've toyed with it, and I can see the usefulness of the particular data model. But the implementation always smelled ... flawed. But I never investigated because, well, frankly I don't have time for that shit. Other people can use it, and I'll keep using postgreSQL for my projects, and if it turns out to be a million times better then it'll all come out in the wash. I did take a good long hard look at FoundationDB. If you're looking for something like MongoDB that isn't shit, that has the option of having an SQL layer, that scales horizontally in a somewhat linear fashion, take a look. It's not free after a few nodes, but it's pretty cheap. There definitely is a need for this kind of thing, it's just MongoDB isn't the thing.
TimesTen, a product now owned by Google, is an in memory database...
Just a little off about who owns it: https://en.wikipedia.org/wiki/TimesTen
Because they're both massive and slowly taking over the world, whether you like it or not. You're just a couple years off in predictions of whether they will successfully take over the world and # of failures / irrelevant items they have under their belt. I'm sure Google will be much easier to compare to Oracle in a few years, especially for us younger folk.
These "mongo is bad" articles always, always fail to acknowledge that (1) schemaless is a thing people want and need, and (2) nothing else comes anywhere close to Mongo is terms of ease of use for storing big, weird-shaped JSON documents. The kind of data that Mongo is good at makes relational databases melt their disk arrays. Yeah, it's not as fast as a normal relational database, so what. That's not the purpose.
I honestly never saw a particularly compelling reason to not use a relational database in pretty much any setting. It's not surprising that the young upstart that landed with a giant splash turns out to be better at marketing than at doing what it claims on the tin.