An ORM is both a more native way to represent data rows in the application and a convenient wrapper to automate much of dealing with SQL and result sets. But on

An ORM is both a more native way to represent data rows in the application and a convenient wrapper to automate much of dealing with SQL and result sets. But only a fool would wish to see an ORM as an object-based abstraction over SQL. Dynamic languages such as Lisp and Python can often make-do without a specific ORM layer because it's easy to stash data into lists and dictionaries. If you can read rows from your result set into a list, make dicts or structs out of each row, and pass around that list or its entries to various functions you've just implicitly implemented a LRM: lispy relational mapping. But sometimes it just fits to create objects out of rows. Simple wrappers will do for an ORM: the best kind always make it clear that you're just using a machinery to operate an SQL database instead of updating an object and then "saving" it back to disk in the end.