I probably made that too confusing. I only mentioned the restores because the availability story for PostgreSQL is very poor and backups above the low tens-of-g

I probably made that too confusing. I only mentioned the restores because the availability story for PostgreSQL is very poor and backups above the low tens-of-gigs are fairly pointless if you have SLAs to meet. The reason why NoSQL would be popular with startups (IMO) is because it's easy to outsource the administration, they're relatively inexpensive, and they're typically much faster when faced with limited resources (both hardware and skill). I like to think I know my way around your average RDBMS, but there's still no question that tuning your average database is non-trivial unless you're very familiar with the schema, data, production hardware and performance requirements. I'd echo your sentiments on MongoDB, but that's my own personal prejudices. Probably just from reading about so many horror stories and what sounds like to me at least questionable implementation choices. Four nines on a monthly SLA means you can suffer less than 5 minutes of outage without penalty. I just wouldn't bet on PostgreSQL to deliver that. I'm not entirely convinced that a third party can either, but I think BigCouch itself fundamentally can get you there in a way that PostgreSQL can't. PostgreSQL is extremely reliable, but if you try to automate failover you could really shoot yourself in the foot and be looking at a nightmare of an outage recovery. If you go with manual failover (my choice) you're just going to have to accept that if/when you do need to failover, you're going to be able to consistently do it within minutes, but it's not going to be less than 5 minutes. IMO HA is just one of those things that really has to be baked in at a design level.