You're right. It's easy to compile, configure, and start on a dev VPS. It's easy to fill with data and easy to query.
This is the sweet spot: when MongoDB is on a dev VPS and you're building a small product around it. Most devs don't have to worry about the next step.
Then you push everything live. If you're lucky enough to get any real traffic, everything other than 99% read crumbles. You scramble to shard but realize that sharding just doesn't work well, and is incredibly complicated to set up.
Then you start losing data...because the drivers are programmed to not fucking check if the data you sent was actually written (yes, I know, this is fixed). Ok, you set your driver on your flopping app to validate writes, and BAM there goes 80% of the write performance 10gen promised you.
The solution? Just add more shards!! Ok, so now I have 4 shards, each with 3 repsets + 3 config servers. 4 * 3 + 3 = 15. Fifteen servers to handle what one MySQL server could do in its sleep.
Conclusion: MongoDB is terrific as a write-only, developer friendly database that you will never have to scale, ever.
I wish I could upvote this comment more. I have to run over a hundred instances of MongoDB to equal the performance I could get from ten Postgres boxes, but now we have such massive lock-in on MongoDB we can't easily refactor.
The main issue is it being a JSON document store, and our application being designed around that and using the very specific MongoDB queries that involves.
Any wrapper would likely be worse than just keeping MongoDB.
We have the exact same issues with Mongo-specific queries. Even worse, our indexing regime (because we store relational data in Mongo) demands that we stick with Mongo 1.8, so all the comparative goodness of 2.x is lost.
And just this week, it was determined that there won't be any migration from Mongo to something-SQL in the near future, because it'd be too risky to attempt to translate a schema that's half foreign keys, half embedded JSON.
