I wince every time I use application code to do what I know SQL can do faster and easier. ORMs are nice but it's often impossible to translate performant SQL into the ORM's API. SQL is just so concise.
Doing data retrieval and manipulation with application code instead of SQL is like doing web layout with JS instead of CSS or doing graphics with canvas instead of HTML/SVG.
Sure it's more flexible, but it's also far less simple, readable, and in many circumstances less performant.
"Rule of least power" is a good principle. [1]
So now when someone ask me for some data, I need to code, manually joining objects instead of crafting a quick SQL query and using the export to CSV function.
Dictionaries (C# key value collection) have fast become a staple diet since Linq is way too slow when you try to 'join' hundred of thousands of objects together.
It feels backward (and I'm saying this as a dev, I'm certainly no DBA or SQL expert).
The first reason was GDPR compliance and the second is that we have an already complex architecture as it is (and we're only 2 to manage it) so I don't want to add one more brittle layer that will need debugging at the worst time.
They do.
Being able to join data in SQL or GraphSQL is a 10x time saver.
As the sibling commented, I often create a shadow database though of course isn't perfect.