I'm a little blown away by the total lack of technical understanding when it comes to MongoDB. This person is obviously very technical, so why would he have chosen MongoDB in the first place? It isn't like MongoDb's technical shortcomings are a secret. The description of how MongoDb does sharding and distributed queries should have immediately raised red flags to any who has even a modicum of CAP understanding. If it sounds complex, a total hack and impossible to manage it probably is.
For gosh sakes, even the 10gen guys admit MongoDB lost data a year(!) ago. [1] If a database lost data in a single server configuration, why would you trust it as a cluster?
Because developers without significant database / data store experience are choosing where to put their data because its "easy to use".
Yes, RBDMS and similar approaches are difficult to work with [1] and introduce "impedance mismatch". Yes joins can be slow. Yes scaling can be difficult and or expensive. But, when choosing where to put data without understanding (or accepting) why the above is difficult is only asking history to repeat itself.
[1] "Database guy here". I know databases and SQL. I would not consider choosing what language to implement a web application tier on, because I don't have enough relevant experience. I focus on what I have battle experience in.
"Easy to use" is a perfectly legitimate criteria to optimize for. For most startups performance/scale is a total non-issue, most of the time even something like berkleydb would do. At most early stage startups developer time is the single biggest bottleneck.
If you make a non-optimal choice upfront you can always migrate to another database later on (database migrations are painful but in practice is something you have to do sooner or later in any case).
(obviously this applies to the scaling argument; if you need transactions you should pick a database which supports them)
... which is why any company with an "Architecture Group" has lost its way. When you have a small group that is rewarded with the job of playing around with new technologies and pushing them to the rank and file to implement, bad technical decisions will follow.
(I have a rant for the "Scrum Group", aka "the Agile Police", but I'll save it for another opportunity)
My point was, sometimes you, as the the person who needs to make it work, weren't the one that chose what to use. You have a job, to use this tool for this task. Do what you can.
If a database lost data in a single server configuration, why would you trust it as a cluster?
Please be serious here. EVERY database has had at one point lost data due to a bug. It doesn't mean that there is some systemic problem that means you should jump ship immediately.
To this day Foursquare who are the ones referred to in the article still use MongoDB:
I was more surprised by a technical post complaining about workers, waiting on io, and context switching. There are ways to handle concurrency and network communication without large amounts of context switching and threads.
For gosh sakes, even the 10gen guys admit MongoDB lost data a year(!) ago. [1] If a database lost data in a single server configuration, why would you trust it as a cluster?
1: http://www.dbms2.com/2011/04/04/the-mongodb-story/