This is a summary. For a deeper dive, read the LinkedIn article.
Raw SQL vs. ORM is one of those debates that can easily turn into a team identity argument. I do not think it should.
The useful question is not which side wins. The useful question is what problem the team is trying to solve.
Before ORM, an application usually interacted with the database through a driver such as JDBC or ODBC. The developer wrote SQL, executed it through the driver, read the result set, and mapped the data manually into application objects.
ORM added a wrapper around that work. In the Java world, Hibernate became one of the best-known examples. Its origin matters: it was created to solve real pain from older enterprise Java persistence models and to let developers spend more time on the business problem instead of repetitive persistence code.
That does not make ORM a replacement for SQL.
ORM is strongest when the application has a meaningful domain model and the persistence abstraction removes enough repetitive work to justify its cost. It can help with complex relationships, caching, transactional behavior, and other patterns that are hard to hand-code consistently.
ORM is weakest when a team uses it because it is uncomfortable with databases. That is the wrong reason. The abstraction leaks. Generated queries still matter. Indexes still matter. Bulk processing still matters. Database behavior still matters.
Every developer using an ORM should still understand SQL and the relational model well enough to inspect what the ORM is doing. The tool builds on database knowledge; it does not replace it.
My conclusion is boring on purpose:
- raw SQL and ORM are both valid choices
- the right choice depends on the problem
- ORM was designed to solve specific persistence problems
- using ORM to avoid learning SQL is a bad tradeoff
- sometimes the debate matters less than people think
The winner is not raw SQL or ORM. The winner is the team that understands its own workload and chooses the abstraction with open eyes.