FWIW, Foursquare's situation was kind of unique. They have a need for all of their data to be in RAM. In most applications, you can define a working set of data. As long as you can keep that working set and indexes in RAM, you'll be fine.
I have not used mongodb for anything sensitive (just log and test analysis), but my experience is that while at least the index stays in ram, things go relatively well, and degrade much worse than mysql once it does not.
My experience with MongoDB (300GB database; most of which was insert-only, but some large chunk of it was being updated) under constant load was horrible: I would not go back there. I've since spent a lot of time learning more about PostgreSQL's implementation and figuring out how to tweak more performance out of it. At this point I no longer believe there is any benefit to using MongoDB at all.
You could run into problems but one option to deal with this is to "scale out" to a larger number of machines and shard the data onto each separate machine (with their own RAM) as appose to one or two high RAM machines.
This bears repeating. Because MongoDB doesn't do joins, sharding is orders of magnitude easier than with an SQL system; if you run out of RAM, shard.
As long as your working set of data and indexes fit in RAM then it should perform well.
This needs some serious proofreading.
Sorry, it was posted before I actually finished due to a communication error. I tried to fix some of the problems & I apologize.