Eh, that heavily depends on language and dataset you're working with. I've seen "simple" data with some fat thing like RoR on top of it having 10x the latency of the underlying database after all the ORMing.

Most of my experience with this actually comes from RoR. I worked on one so where rendering slowed everything down to a grind, but more often than not it was making Yu noptimized queries, too many queries, inefficient calls to other services. I used to work as a consultant, so this was true for quite a few apps. However, I also usually was the person most interested in relational databases and my view might have selection bias.

I have a similar experience. Also, for the longest time Rails was also incredibly slow at generating JSON, of all things. JBuilder [1] was a few orders of magnitude slower than using .to_json directly or other libraries.

[1] https://github.com/rails/jbuilder, maintained by DHH and the Rails team. AFAIR, the "official" JSON serialization DSL.

I’d like to work in one of these teams/products where the database is the bottleneck. Basically everywhere I’ve worked, I’ve had to work with backends that have been foot-draggingly slow compared to the actual database.

Just work with some folks who don't know basic query optimization

Except when it isn't. I remember an article making rounds the other day, that claimed the whole "most software spend most time waiting on I/O" common wisdom is no longer true, as most software these days is CPU-bound, and a good chunk of that is parsing JSON.

For pure compute most software is memory bandwidth bound and for large applications I/O is generally still a problem given the costs of flash.

> For pure compute most software is memory bandwidth bound

This is related, though. While the final leaps of performance often come from using more memory to make CPU work less, in my experience, most of the performance-problematic code wastes both CPU and memory, and meaningfully faster alternatives end up using less of both.

Either way, from the end-user perspective, I tentatively agree with the article I mentioned (but don't have a link handy, sorry) - most of the software I end up using, or see people around me using, is clearly CPU-bound, briefly network I/O-bound (mostly web apps), and rarely local I/O-bound.

EDIT: I guess the caveat is that end-user software is often spending 99% time doing nothing at all, just waiting for user input. But that bit doesn't matter - what matters is how fast it reacts to the input once the user starts providing it. This is where a lot of software suddenly gets CPU-bound (or net IO-bound, if doing something stupid).

Yes, because of some clean and readable way (for the developer) the code uses to interact with the DB...