Must have missed that meeting. ORMs are not for everything, but for CRUD-heavy apps with validation they save a lot of boilerplate. And there's always execute_raw() for when you need to go off-script.

If there's an Open Source application that you can show me as a good example of ORM usage, I'd be interested in seeing it as a steelman argument for them.

Here's OpenEdx extensively using ORM: https://github.com/openedx/openedx-platform

For Oxyde specifically, it's still a young project, so the best public examples I have are the FastAPI tutorial (https://github.com/mr-fatalyst/fastapi-oxyde-example) and the admin panel examples (https://github.com/mr-fatalyst/oxyde-admin). Bigger real-world showcases will come with time. But in general, ORMs pay for themselves when you have lots of models, relations, and standard CRUD with validation. The moment you hand-write the same INSERT/UPDATE/SELECT with joins for every endpoint, it adds up fast.

Micro-orms (mapping to parameters and from columns) are generally fine last i read. It is the general aversion to writing a SELECT that is suspect.

Where ORMs are clearly weak is in generating suboptimal queries and making it too easy to create N+1 issues. My first introduction to ORMs was Ruby on Rails. You would rely on New Relic to identify performance issues and then fix them.

With solid AGENTS.md / CLAUDE.md, I do not think this would happen as much anymore in new code. So then it is just a matter of style preference (ORM vs whatever else).

That's exactly why Oxyde has no lazy loading at all. If you don't call .join() or .prefetch(), related data simply won't be there. N+1 is impossible by design, not by discipline.