Im prepared to jump through certain hoops in using bigtable (mostly the hoops associated with not being able to use joins) because, working on my own pet project as the only edveloper with a miniscule budget, a bit of design/development tomfoolery is something I CAN accomplish.
Purchasing and learning how to design and maintain a RDBMS cluster is not something I can accomplish.
Its a simple equation for anyone in a similar situation.

These guys knew so much about relational databases, that they had an instant awareness of when they *shouldn’t* be used.

At yahoo we used a home brew database that sounds something very much like simpledb – completely unstructured and unenforced – and taught me everything i needed to know about choosing the right db tool for the job.

But we also had some massive oracle systems too, for stuff like data mining and the directory.

But when it came to serving users pref data t page time, hitting an sql query was absolutely verboten.

This is why you see companies such as dig run into 5-year scaling nightmares with mysql – all you need to know about mysql is that requirements are unique and mysql can scale some stuff ok, some stuff not at all, and some stuff you can scale but living with the implementation will make you cry like a little girl.

My point is none of these databases are ‘sucky’, but instead fulfill different sets or requirements.

Much more often then someone choosing one of these for simple stuff, you will see developers just try to cram every data problem into mysql.

Your most valid point though is that fewer bytes of data must be transferred if you push the functionality down to the server. This saves enormous time and is a basic functionality of a true Database server and not just a datastore.

#2. That's completely application dependent. Consistency usually comes with performance tradeoffs. Some apps would much rather accept the write and then reconcile it later (asynchronously), than force the user to wait and block until such a transaction can be completed due to all the lock contentions that can happen in a high traffic environment. Again, it's very application dependent, but what you're describing is called “Eventual Consistency”, you can read more here http://queue.acm.org/detail.cfm?id=1466448. RDBMS themselves are not necessarily the bottlenecks, rather it's ACID transactions which are. Every high load/concurrency app eventually trades transactional semantics for performance. It's up to your application to figure out how to reconcile temporal inconsistencies if at all. If you still think it's that important, just ask eBay. They don't use transactions and utilize the eventually consistent model? What does that mean, it means that there might be a very minuscule chance of some inconsistency and they might have 1 out of 100K spooked customers, but who cares, they've just achieved a 99.9999% customer satisfaction, as opposed to many unsatisfied customers if their system is somehow unavailable or slow.

#3. Probably, but the same is true when you shard a sql database. Also, through map reduce operations, aggregates are actually more natural and some key/value DBs now provide such operations. The great thing, map/reduce is completely abstracted from distributed database semantics, so you can easily distributed this operation over numerous remote nodes.

#4. Not sure what you mean. Maybe they'll require non-SQL coding, but not necessarily “more” coding. And coding might actually be shorter as in some languages you utilize a Turing complete language to apply predicates vs. the limitations of SQL and it's underlying relational model. Again, it's true that RDBMS are more suited for reporting at this time, mostly because they've accumulates lots of experience over the years. On the other hand, if reporting is not a huge part of your system and you want it in a relation database, just replicate. Data warehouses do this all the time to optimize/denormalize data for reporting, as reporting on highly normalized data is also very inefficient.

#5. I think that's a side-effect of the network. Yes, it's true that RDBMS algorithms might have been more optimized over the last 20 years, but that doesn't stop from NOSQL DBs from getting faster. Basically, there is no theoretical reason for a “local” NOSQL query to be any slower than RDBMS. It's all in implementation details of that db, storage structure, search algorithms, etc… Because SimpleDb is distributed, the side effect of aggregate functions is “more latency”. The same side effect would be true in a sharded RDBMS.

#6. RDBMS might have more tools now, but again, that's not a reason to necessarily disqualify the benefits of a different storage model. Also, have you looked at CouchDBs replication? Talking about fast and easy.

#7. See #5 response. Also, SimpleDb wasn't designed to be fast per say, although that wouldn't be a bad feature. It was designed to be linearly scalable, so you might incur some latency, but that latency should be constant with increasing load.

#8. Nonsense. There is a sweet spot for RDBMS systems and I use them in any applications which has a requirement for such and/or where the data fits into the relational model. I hate having to square pegs into round wholes. Like storing highly dynamic and hierarchical data in a relational database, either using a convoluted normalized model or using skinny tables, which defeat the purpose of the relational model completely. Also, you mention Facebook, MySpace, etc… Yes, they use a RDBMS engine behind the scenes, but if you look at their storage model, they are utilizing it just like a key/value store. Basically, they're not benefiting from any features that RDBMS systems are good at.

#9. Agree, you don't want to make that the top priority unless you have to. But I think many people read “don't optimize prematurely” as a ticket to forgo such activity. That's the worst thing you can do. I faced that personally, when you only worry about features and not the long term requirement changes/scalability and then your system fails in production due to an unexpected load which you never accounted for and/or thought a your architecture can handle. What then? Well, besides making up excuses and trying to savior any of the relationships that still exists with users, you're up for 2 weeks straight not sleeping doing what you should have done upfront. That's like building bridges and only being able to handle 5 cars on a bridge at a time, because in this rural community we'll never have traffic. Disastrous results await.

#10. No shit, everything is useful only in certain contexts.

Problems arise when you're trying to square the circle. When your application needs aggregate functions or joins, nosql is not the way to go. When your app doesn't need a lot of personalization in terms of aggregation (say, statistics based on user preferences) you can just reverse the problem, and generate and update aggregated data as they come in.