One ORM I've used recently which does some cool stuff is Diesel, for Rust. On a few of these counts, I think it does quite well: > Efficiency is "good enough"

One ORM I've used recently which does some cool stuff is Diesel, for Rust. On a few of these counts, I think it does quite well: > Efficiency is "good enough": none of the ORM layers I've seen claim efficiency gains. They are all fairly explicit that you are making a sacrifice of efficiency for code agility. If things get slow, you can always override your ORM methods with more efficient hand-coded SQL. Right? Relevant GitHub PR: https://github.com/diesel-rs/diesel/pull/283 https://github.com/diesel-rs/diesel/pull/283 -- Diesel's query builder is often faster than a raw SQL string, and the queries are typechecked against a provided database schema at compile time. > When you fetch an object, which of its properties (columns in the table) do you need? ORM can't know, so it gets all of them (or it requires you to say, breaking the abstraction). Initially this is not a problem, but when you are fetching a thousand records at a time, fetching 30 columns when you only need 3 becomes a pernicious source of inefficiency. This is trivially easy to avoid in Diesel (and, I suspect, in other ORMs I haven't yet used. Just add a .select((tuple, of columns)) function call to the start of any query you're building. > Entirely anecdotally, I claim that the abstraction of ORM breaks down not for 20% of projects, but close to 100% of them. IMO a good ORM allows seamless integration of "raw" SQL through the use of type-checked function calls which integrate into the rest of the ORM. Diesel does this, and IIRC so does SQLAlchemy. > Objects are not an adequate way of expressing the results of relational queries. Right. But an ORM need not always force returning objects. Diesel (and again, IIRC SQLAlchemy) are examples.