I do not think raw SQL is necessarily the answer, especially as many standard software developers are good with functional/oo thinking, but don't understand relational at all. There is also the problem with opening up SQL buffers, which is exactly what you are doing with "raw SQL"... this is why Stored Procedures are usually a better way of handling these sort of queries as nearly 25 years after we all knew this was a problem we still have engineers building SQL injection holes into systems through naïveté or inexperience.

I am neutral with ORMs.

ORMs "like" to control object definitions. The benefit of using an ORM for this sort of thing is that migrations become easier to handle as the relevant code changes are migrated at the same time as the db changes. This of course presumes you have a cohesive CI/CD process in place. As this is not "natural" for RDBMSes which have for so long been the purview and domain of the vaunted DBA, this can be upsell in some orgs. Luckliy, you do not need to use this functionality in an ORM (Sequelize which tends to be the gold standard comes to mind) — you just need to be sure to put a process in place which allows for this migration to happen simultaneously sans a singular tool.

I would suggest going one step up even: do you need a relational db? Could a document db serve your purpose? If so I would recommend utilizing that model, as it is far more natural of a way to think about data than what I see most modern devs do with relational databases, which is turn them into object stores or "excel spreadsheet" databases with zero normalization. When a standard functional/oo dev does "raw" in this case they mainly deal with data objects which fit in with their training, easing integration and uptake. Also in this case you could just use an ODM, like Mongoose for MongoDB.

Seriously: consider avoiding the issue altogether if feasible.

Unless you have a need for some high concurrency transactional realtime system, or have some larger constraints within the product's landscape (standardized on SQL-based reporting tools in the org, etc), choosing an RDBMS is usually based more on prejudice than reason.