I work a lot with EntityFramework (the "unit of work" pattern) and it does solve the issues the author brings up fairly well: queries are first class (LINQ with

I work a lot with EntityFramework (the "unit of work" pattern) and it does solve the issues the author brings up fairly well: queries are first class (LINQ with static typing), and transactions are on by default between each .Save operation. However it's not a magic bullet by any means: EF will still sometimes generate weird join queries that require serious head scratching and second guessing to get into a better form, and huge nested .Include / .ThenInclude trees are extremely common when your data is highly normalized. This can lead to the same kind of inefficiencies seen with the ActiveRecord pattern. FWIW what really slows things down isn't typically selecting every column, it's those really giant joins or joins on things that aren't indexed. I think there's some room for improvement in the DX of EF itself here -- it could at least tell you if you write a join on a non-indexed column. (It has all the information there, as the indices are defined in EntityMap source files). Overall, when building applications on a RDBMS <-> OOP <-> REST API, there are indeed different fundamental abstractions, and no framework or library will save you from needing to understand how those abstractions map between each other. And believe me, GraphQL is also no panacea! It has its own similar but different issues.