Disagree. The point of this article as I understood it was not to provide short advice, but to provide a comprehensive explanation of the problem and why the 3 listed solutions are good ones.
People often ask "why use bcrypt", and the response is that they should google it. If you look through the first page of google results for [why use bcrypt], though, none have a good discussion of the reasonable alternatives, or when you might want to use one or the other.
Coda Hale's post has a pretty good explanation of why bcrypt is good, but I personally find this to be more in-depth.
Why can't the hosted service use an "encrypted file in the cloud" as its implementation? As long as it requires client-side code to do the decryption, the key stays in your head alone.
[1] looks like an example where the data didn't fit in RAM. Mongo works best when data fits in RAM or if you use SSD's. Yes, it's sub-optimal.
[2] is from a year and a half ago. It doesn't belong in a sentence that includes the word "still." I work at foursquare, btw. Those outages happened on my first and second days at the company. I wasn't so keen on mongo then either. We've gotten much better at administering it. Basically all our data is in mongo, and it has its flaws, but I'm still glad we use it.
[3] is also from a year and a half ago. Mongo 2.2 will have a per-database write lock, which is at least progress, even though it's obviously not enough. Since 2.0 (or 1.8?) it's also gotten better at yielding during long writes.
I have no experience with their mapreduce impl and can't speak to it.
I disagree that sharding can ever be a trivial problem if you're going to try to tackle moving data between shards while staying online. I'm not saying it's impossible, just that it's not trivial.
My definition of seriousness includes some relatively large scale. Your definition of seriousness appears to mean any site that is important to the person or business running it. Is that a fair assessment?
I think your definition is better, and I should've said "a potentially-large site" or something like that.
Fair, my statement was overly broad. Sites that are read-only or store blob data in something like S3 can often avoid sharding for quite a while and rely on machines to just get bigger over time.
That said, if your site grows in some way you didn't originally anticipate and you get to a point where you need to shard, but can only do so by changing data stores, then it's sad.
I don't know if it's the _most_ important feature, but I wouldn't build a serious site on top of anything that didn't have some sort of built-in sharding story.
With postgres you have to roll your own. If you want to bridge the gap from postgres to mongo, I think that's where you have to start.
The implication is that the Great Firewall will see a GET for google.com/search?q=[any of those characters] (or equivalent) and not let you get to google for a minute afterward.
Someone asked me that once, and I thought it was a great question, so I stole it.