However, a good RDBMs will have a large cache of commonly accessed data, so in your /places/list/ and /places/detail/ example, if the a user has already queried for /detail/ the performance cost of /list/ will be largely in the network call to the DB & the query parsing because all the I/O will be in-memory (assuming the data isn’t dirty from a write that happened in between the read queries). But scaling a read-heavy database is actually fairly easy, especially if writes can be eventually consistent. The problem is more interesting when you have a write-heavy database with strict ACID needs.

What ORMs could attempt to do is ongoing, lightweight instrumentation (like a sampling profiler) so the ORM can tell when the query is running very slowly; the problem is that the ORM knows nothing about the physical structure of the database nor anything about were the RDBMs is actually spending time (query parsing? query execution? Block I/O? Block contention?) so the ORM will never be able to optimize away the biggest problems in scaling traditional RDMBs (I/O contention) and the problems in database performance (the aforementioned contention and also query execution). Oracle and other “enterprise” RDBMs spend a lot of time trying to get their query optimizations correct use dynamic analysis, profiling, hints, and other knobs, and they don’t do such a great job at optimization despite all of that data.

Umm, not sure where I’m going with this. But you should check out object databases, they may be the droids you are looking for.