Erik Darling gives us some hints on when it might be time to stop using that ORM:
There are, unfortunately, some times when developers refuse to put the ORM down.
I mean, it’s mostly unfortunate for them, because they’ll continue to have performance problems.
Me? I’ll be okay.
The items in this post are issues I’ve run into constantly when working with people who use ORMs, but don’t spend any time looking at the queries they generate.
An important note is that “stored procedure or ORM” is a false choice—most modern ORMs will allow you to generate objects based off of stored procedures, so you can stick with the ORM for the parts it does well but switch to a stored procedure when things get real. Or just use stored procedures across the board and have your ORM act as an auto-mapper for them. That’s an option too.