I promised myself I wouldn't respond to these anymore but I can't help it.

> Separate filtering from retrieval

Why? What does this buy you? You're already doing stuff in the DB. Why make another round trip after the application layer has decided it needs more stuff? We did this everywhere in a previous iteration of the app I work on and it was terrible for performance. You might actually make the DB do more work here since it has to do double the queries (and connection overhead).

> Avoid performing operations on returned results

I guess this is the one valid point but honestly I haven't run into this much beyond some averages and summing (e.g. a balance is the sum of debits and credits). I'm okay with having those in the DB because they rarely change. What happens when someone wants to filter on one of these calculated values, though? Do you do that in the application layer too? How does Bob use his BI tool to get the data he needs from your application layer?

> Move joins into the application layer

Yep, ship all the data over the wire then write your own code to match them up. More code to maintain and possibly slower! Again, what is this buying you other than some handwavey, vague promise of "scalability"?

There are reasons not to put logic in the DB but I don't feel like these make a good argument. Someone will keep parroting these points, though, all in the name of made-up constraints (e.g. "must scale") that were never actually needed. After all, with the architecture he proposes your app will be bottlenecked on the DB either way so might as well move the point that it happens further back. It's a sample size of 1, but every project I've worked on has had positive performance benefits by moving computation closer to data rather than just adding computation. By doing that, we didn't have to "scale" until much later.

Does it make sense to put all of your logic in the DB? Probably not. Does it make sense to put some logic there? Maybe! Test, evaluate and have an exit plan if it doesn't work, but absolutely never, under any circumstances listen to absolutes like this article.