I used MongoDB in a medium-sized production environment (Aol's Editions backend, which I built with my brother). The sharding, for our needs, was far from autom

I used MongoDB in a medium-sized production environment (Aol's Editions backend, which I built with my brother). The sharding, for our needs, was far from automatic. In fact, the only way to get MongoDB to shard records evenly across servers (this is with 1.8) was to for all intents and purposes implement our own sharding on top of it. In other words, the global write lock coupled with worthless auto-sharding (at least given our purposes: high write, temporary but mission-critical data) made MongoDB a PITA. That, along with the fact that we were more or less told that MongoDB would be able to handle what we were planning by the MongoDB consultants Aol hired completely soured my view of 10gen. The only reason we needed sharding in the first place was because we were getting large amounts of queued writes on a 32GB server with 16 cores (with < 300 w/s). Pathetic. My point is that if you want to spread out your writes on a database that supports rich queries and honors the "C" in CAP, you're going to have to do some work. The distributed DBs are nice and shiny if you can forego some of the nicer querying features of relational DBs (or MongoDB), but not everyone's requirements fit into document-based records, and to assume they do is just NoSQL fanboism. Note: I am using MongoDB for my latest venture because we are realistic about it's abilities and also because our development time with MongoDB is no joke about 1.5x-2x faster than with MySQL (or equivalent). So MongoDB has its place and it definitely a good system (especially after v2) but NoSQL isn't for everybody, especially if you can't get past the hype and look at decisions very technically and objectively.