This is exciting. MongoDB (and the suite of libraries building up around it) has made prototyping web applications an order of magnitude easier than using SQL. Lack of single-server durability, however, is a showstopper in production, before you've grown enough to justify scaling the database beyond one machine.
In my case, that meant going back to MySQL once our schema was finalized (sadly). Looks like that won't be necessary in the not-so-near future, which means MongoDB is usable in new projects without worrying about replication before otherwise necessary.
I have an app I'm working on launching right now, it's in what you might call 'private beta': real people accessing the app is <10. It's been in this state for a little less than 2 months and there's been a replica-set and backups happening since even before that.
What I'm saying is that you don't need to grow before adding a second box. My project currently runs on ec2 micro instances and the second box will probably cost you less than your GitHub code hosting costs! Just seems to me that (in ec2 terms, as an example) going from $9/month burn to $18/month is hardly a show stopper.
Aren't micro instances $15/month? (Plus EBS backing, unless you want to lose your DB on reboot.)
Regardless, it's added complexity that you can avoid with MySQL early in your application's lifecycle. Even if it's not much more expensive, you have more hardware to administer. Compare that to a Rails+MySQL stack, which you can run on a single box. (There are added benefits of replicas, sure, but they aren't easier to set up, per se, then just installing your stack on one machine when you're getting going.)
Yea sorry $15/month (EBS is practically free, as is Elastic IP), but anyway my point still stands at $30/month. I think you'd be hard pressed to find a developer who doesn't spend that much on coffee per month (not to mention merchant accounts and support and code hosting and bug tracking and blah blah blah) :)
As to the rest, sure, it's sys-admin-wise easier to setup. But then you have to consider stuff like database dumps/backups. Where are you storing them? Have you tested your recovery plan? Then there's hassle when you decide you need a dedicated db box and move it there (friday fat-finger, anyone?). True enough that none of these are deal-breaker level issues (evidenced by the ubiquity of MySQL/etc).
With mongo you spend a tiny bit of extra money and a tiny bit of extra time setting up a replica set which handles your backup for you. And then when you need more db horsepower you just start sharding or just adding more replicas and sending reads there. Need to upgrade the db box? Cool just add a huge instance, add it to the replica set and promote it when it's done syncing.
I certainly agree that it's a trade-off... it's just one that I think is not driven by data durability. Either way I need to handle my disaster recovery with some kind of automated system and I'm just suggesting that whether this is some kind of cron-job, restore recipe, etc backup of a db-dump or a replica on a cheap extra box is a wash.
In my experience, using CouchDB for prototyping is not fun. With SQL and (from what I gather) MongoDB, you can create ad-hoc queries as you go. Creating views in CouchDB requires thought and time -- usually lots of time -- to generate the views, unless you're working with a very small amount of data. Changing your mind is painful. You end up using weird hacks to get around rebuilding your views all the time.
Maybe I was doing it wrong, but it seems like if your app has more than a little data and you plan on changing your mind about how best to present it, you will experience discomfort.
I don't have any experience with MongoDB, but I am building an application right now using CouchDB and I've found it to be pretty easy to use -- definitely easier to prototype with vs a relational database + ORM framework.
CouchDB supports ad-hoc queries in the form of 'temporary views'. The downside (and I think a difference compared with MongoDB) is that temporary views can't be used in production since they are not indexed and thus are much slower than permanent views.
I'm developing my application in Python, which has great support for CouchDB in the form of CouchDB-Python (http://packages.python.org/CouchDB/) and CouchDBKit (http://couchdbkit.org/). Using CouchDBKit, it was pretty easy to set up CouchDB artifacts (map functions, reduce functions, design documents) into a nice file/folder hierarchy and write the simple Python glue code to deploy updates to CouchDB via a single shell command.
so far we're going with couch and haven't experienced this. the best part of course is that we can add items to documents on the fly whilst keeping the existing test data! this is major for us. we can go back to testing right away. with MySQL the changes were so major that it was better just dumping and recreating from scratch (we are using django) and this wasn't exactly fast. django has a project "south" that would help with this, but we're eventually deploying to oracle and cannot rely on it or have the time to extend it to properly work with oracle.
In my case, that meant going back to MySQL once our schema was finalized (sadly). Looks like that won't be necessary in the not-so-near future, which means MongoDB is usable in new projects without worrying about replication before otherwise necessary.