#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.