I think there are a lot of loaded expectations on what it means to be an ORM. Maybe this is no-true-scotsmaning, but I distinguish between things providing conv

I think there are a lot of loaded expectations on what it means to be an ORM. Maybe this is no-true-scotsmaning, but I distinguish between things providing convenient query builders from full ORMs. Generally speaking, I'm happy with anything that handles marshalling / unmarshalling and can generate typesafe (when applicable) queries for me (so long as its happy to get out of the way on those handful of occasions that I'd like to use some handwritten SQL). Things I've used in the past like this include * Knex - http://knexjs.org/ * Slick - http://slick.lightbend.com/ * Opaleye - https://hackage.haskell.org/package/opaleye Generally these don't call themselves ORMs though. The primary distinction I've found is that they don't conflate my domain model with my schema. They don't enforce a 1:1 correspondance to a table or a try to concoct some scheme of representing inheritance with multiple tables and they don't try to take on myriad other unrelated duties like validation, etc. They allow me to build my application in the hexagonal style ( http://alistair.cockburn.us/Hexagonal+architecture http://alistair.cockburn.us/Hexagonal+architecture ) in an OO language. Abstraction of SQL is not something I have a problem with, its trying to infect my domain model with persistence concerns, or even worse by trying to pull transaction handling out of the domain of the database.