Exactly my point, all those nice things RDBM's give you come at the cost of performance trade-offs. Relational databases are never the fastest option, they are the safe conservative option.

The bill of goods that RDBM's sell is that data integrity trumps all else. The reality is that is doesn't. Data can be cleaned and integrity maintained by background processes if the performance you get is more important to you than absolute up to the second data integrity. There are lots of cases where available data is far more important than up to the second accurate data.

Eventual consistency is more than good enough for many many things common web applications do. In many cases it's perfectly fine that the web app is looking at 4 or 5 hour old data, it just doesn't matter, what matters is that it can look at it in milliseconds without having to rebuild it on every query.

While I ultimately agree with you, I think that the safe conservative option should be the default. By the time peoples' systems are large enough for the performance difference to actually matter (if ever), they will have had plenty of time to get sufficiently informed about the trade-offs involved. The people who are upset because they get crappy performance from MySQL when they don't even know about indexing tables are not qualified to decide whether risking data corruption is worth a performance boost.

In other words, it's premature optimization.

And I think the simplest solution requiring the least amount of code and effort should be the default. It's not just about performance, it's about implementation effort. The safe conservative option is quite often a lot of extra work.

Most people aren't building banks, for most apps data corruption is not the big concern RDBMS fans make it out to be.