> This is simply not true. Providing a wrapper around a thing is not the same as wanting to turn a thing into something else. I would argue that ORMs offer cos

> This is simply not true. Providing a wrapper around a thing is not the same as wanting to turn a thing into something else. I would argue that ORMs offer cosmetic change. Convenience, not substantive change. > Many ORMs are designed to abstract away SQL and RDBMS concepts entirely. Which ones? Look at their docs and you'll see where conditions, joins, columns, ordering, aggregations, etc. ActiveRecord is probably the most abstract I've seen and the docs still refer endlessly to tables, foriegn keys, etc and show SQL equivalents http://guides.rubyonrails.org/active_record_basics.html#creating-active-record-models http://guides.rubyonrails.org/active_record_basics.html#crea... Here's Hibernate: http://docs.jboss.org/hibernate/orm/5.3/userguide/html_single/Hibernate_User_Guide.html#fetching http://docs.jboss.org/hibernate/orm/5.3/userguide/html_singl... Here's Sequelize: http://sequelize.readthedocs.io/en/v3/docs/querying/#basics http://sequelize.readthedocs.io/en/v3/docs/querying/#basics Here's SQLAlchemy: https://docs.sqlalchemy.org/en/latest/orm/loading_relationships.html https://docs.sqlalchemy.org/en/latest/orm/loading_relationsh... I would say that ORMs as a class rely heavily on SQL and RDBMS concepts... particularly for anything beyond simple CRUD