> You have omnipresent performance problems. There are n+1 queries everywhere, but where specifically? You don’t know. It’s impossible to statically determine w

> You have omnipresent performance problems. There are n+1 queries everywhere, but where specifically? You don’t know. It’s impossible to statically determine where a specific query is happening. You have to instrument at runtime, which is rarely done rigorously or uniformly, tracing every call and staring at logs until you find your performance problems. One of the tools I've really come to enjoy in our modern age is telemetry tools that are designed to solve these kinds of problems. If one finds oneself tasked with identifying the sources of omnipresent database-related performance problems and one is not in a position to rewrite the database access layer for the project(!), I find tools like New Relic to be incredibly helpful. For some setups, they even let you identify the line of code that produces slow queries. Those can then be optimized either within or outside of the ORM. Having pitched both options, I have also found that "let's install this tool, which may be free for our use" to be an easier sell than "let's rewrite the database layer." I honestly found myself tuning out of the essay after the intro exhibited ignorance of modern tooling built to address the specific issues under consideration in the essay. IMHO it still makes sense to use an ORM to build quickly, given that we have tools to help effectively profile downstream. This is the approach we take for code (by using a language like Python and not C/Rust), and the tooling around databases makes the same approach viable for db code.