Your proposed title is very confusing and meta. The current title is only misleading if you are going into it with biased expectations about what it's going to teach you. The article is interesting precisely because it is not just another "NoSQL sucks" screed.
What I meant was that the article was not about MongoDB at all. I think thefreeman summarized it better than me on his reply: the author is talking about his experiences on running more than one DBMS in production, not about MongoDB in particular.
I'm not even saying if the article was interesting or not. It surely has it's merits, it touches a point worth discussing (the downsides of trying to cover one DBMS's weakness throwing in another DBMS in the mix), but I was uninterested. I was expecting to hear why MongoDB wasn't fit for his use case, to better understand when to use NoSQL and when not to, so yes, I was indeed biased waiting for something different—but, in my defense, I say I was biased because the title made me think this way.
That would be a silly point to make. Many people are running multiple DBMS in production without regrets. Each DBMS has strengths and weaknesses in different areas, and for many businesses it doesn't make sense to shove everything into a single DBMS just because things are easier to manage that way.
His point was "in our specific scenario the benefits of using MongoDB were outweighed by the difficulties in having to manage two DBMS in parallel [at a time when MongoDB hadn't been around for long and we had to set up everything ourselves]."
And it depends on how you define "DB". We've recently started using Redis for a number of things, and it has been incomprehensibly faster than our SQL database when it comes to rapidly finding and inserting records in (the equivalent of) a billion-row table. It's also far cheaper to run than significantly beefing up the database server just because of that one bottleneck. Easily worth the time and trouble of setting it up (neither of which was very much).
If you've got data sitting in one place and then data sitting in another, it's generally a massive fucking pain in the ass.
Speaking from my experience anyway. Bonus points if one of them was written by a company in the early 2000s who didn't trust those newfangled RDBMSes to get it right. Extra bonus points if they thought UTF-8 was for sissies.
I don't consider myself to be magical, but anyway — since you were asking.
We primarily use MySQL and CouchDB (BigCouch). Our user records (accounts and payment) are stored the RDBMS, while the data the users created is in BigCouch. We enjoy the schemaless nature, durability and scalability of BigCouch a lot.
Depending on your definition of "database system", we also have a hefty Solr index (for search), some Redis (no persistence only to connect systems/services via pubsub) and Memcache (cache).