We just turned on a product we're calling "Elastic Deployments". These are MongoDB clusters that scale vertically with no intervention. As a database grows, it has access to more RAM, IOPs and CPU. More here: http://blog.mongohq.com/new-elastic-deployments-now-available/
The product itself is neat, but the "startup story" has been one of the more fascinating things I've been lucky enough to experience.
We started working on this general scaling path about 2 years ago. In that time we've grown a lot, raised a series A, turned down acquisitions, watched a small competitor sell to a public company, and dealt with the same stupid startup shit that nearly everyone deals with but you only hear about verbally.
Handling large customer databases has been the canonical "do things that don't scale" exercise for us. We've hand-managed a distressing number of large MongoDB clusters for customers, all in an effort to figure out how best to handle database growth problems in a repeatable way. While doing this, we experience immense pressure to give everyone the same answer for scaling any database (just shard!) ... but our experience with the customers we were working with in the real world just didn't make that sound right.
Over time, we almost lost our religion. Rackspace went hosted MongoDB shopping ... HN only allows 2000 characters, so continue here: https://gist.github.com/mrkurt/7629bab3e9a8016a5fda