I think the Java ecosystem is an interesting example, because it has many different types of ORMs available: Hibernate: a fairly "traditional" ORM, that can

I think the Java ecosystem is an interesting example, because it has many different types of ORMs available: Hibernate: a fairly "traditional" ORM, that can abstract away SQL almost entirely, it even has a DB-agnostic DSL for some use cases (HQL) myBatis: an ORM that lets you write actual SQL in mappers and generate statements dynamically, with conditions/loops/etc. defined in XML jOOQ: an attempt at letting you generate queries in pure Java code (as opposed to the myBatis approach), which looks a bit like the one in the article JDBI: a very lightweight wrapper on top of JDBC, which perhaps isn't a full ORM, but makes querying the database with SQL a bit easier (probably some others, too) Personally, I think that the "Object–relational impedance mismatch" isn't necessarily the worst thing ever in the day to day, when you need to get things done: most ORMs can be good enough, when used responsibly and for the things they actually do well. For example, in my eyes it makes sense to take advantage of DB views and keeping how data is queried (think complex SQL queries) mostly on the DB side, whilst keeping the mappings in the actual ORM layer relatively simple, instead of trying to do a bunch of joins in the ORM. That way, if you ever need to debug how something is selected, then you can simply look at the data in the view, which is going to be the problem in most cases. In my eyes, that's a good way to also avoid running into the N+1 problem too often - if there's a table in your APP (a list in your API) that you need to populate with data, that might as well be a single query against MY_BUSINESS_DATA_V or something like that. As for doing the opposite - modifying data, you might also benefit from simple mappings, perhaps even taking advantage of some of the codegen capabilities available. Point a CLI tool at where an instance of your DB is running and generate your entities from the existing schema (or vice versa). As long as you don't have too complex DB types, it shouldn't be too bad. If you choose a different approach, in my experience you'll spend a lot of time struggling with the internal complexity of the ORM. Hibernate is a good example of this, I've seen people spend entire days trying out how to express their super complex queries in the ORM, not really knowing how to get the equivalent of whatever SQL they need. SQL is good for working with data, so do that whenever it feels like a good fit for your problem. SQL is sometimes worse for certain other aspects (if you need CPU intensive processing for a limited subset of data, subjectively also readability, how expressive the code is, testing, logging, tracing, the available libraries and so on; things that general purpose languages can do better) so don't try to put everything in SQL either. Try to bridge the gap between SQL and whatever language you're using in a low friction way, if possible.