There are less drastic ways to reduce SQL boilerplate, though - such as simple SQL dialect implementations, in your language of choice. I'd almost always prefer that kind of interface, when there's a decent one to use.
Of course, your database may come with features that can help too (views, udfs, etc)
I'd generally only reach for an ORM in one circumstance - when my team already knows it well, and can move fast with it. It should also be popular, so that its likely new team members already know it, and can move fast with it. Otherwise, you're just putting unnecessary obstacles in front of your team, in most cases.
Of course, your database may come with features that can help too (views, udfs, etc)
I'd generally only reach for an ORM in one circumstance - when my team already knows it well, and can move fast with it. It should also be popular, so that its likely new team members already know it, and can move fast with it. Otherwise, you're just putting unnecessary obstacles in front of your team, in most cases.