[cogman10]

Your bad query can not be a bottleneck but can negatively impact the performance of everyone else.

Databases are highly susceptible to the noisy neighbor problem.

Databases aren't magic. If you can do something better or the same outside the database, you should. 1000 cpu cycles are better spent on the application than the database. You can easily add more application servers.

Your general rule is invalid because of this. It doesn't have to be a bottleneck before it can be a problem. It's a "general rule" I particularly hate because I do performance tuning at my company and have OFTEN seen this be a root cause to negative outcomes. Devs using these sorts of shorthands without understanding what their database is and isn't good at. It's right up there with "premature optimization" which gets parroted at me by jr devs that want to write an n^3 algorithm when an n algorithm exists if they'd just use a data structure besides `List`.

Don't shut your brain off when coding. Sometimes it is better to make the database do something, sometimes it isn't. When that is true is context and situation dependent.

[tsarchitect]

I don't think you're disagreeing with OP. Seems like you both reached the same conclusion through different means and said it differently:

"Sometimes it is better to make the database do something, sometimes it isn't. When that is true is context and situation dependent."

"if it can be reasonably done in the database, it should be done by the database”"

In other words, sometimes it's reasonably better to make the database do something, and sometimes it's unreasonable. Context dependent, of course.

[cogman10]

> If that happens to be a bottleneck and you can do better, you should definitely do it in code locally. But these are two ifs that need to evaluate to true

If the OP said what you are saying, I'd probably agree. However, the above statement makes it clear that the OP is saying "put it in the database unless you can prove it doesn't belong there".

That is what I disagree with. There's a lot of reasonable things you can do with a database which aren't the best thing to do from both a system and performance perspective. It is, for example, reasonable to use the sort method on a database. It's also not something you should do without proper covering indexes. Especially if the application can reasonably do the same sort.