SQL is simple for a certain class of use cases, but as a language it lacks a lot of things, or supports features that are difficult to use in practice: * It's

SQL is simple for a certain class of use cases, but as a language it lacks a lot of things, or supports features that are difficult to use in practice: * It's much easier to manage and manipulate variables in the general-purpose language that constructs queries than in SQL * It is practically impossible to compose queries or manipulate their AST. SQL is not easy to compose; ORM languages make composability trivial * The above feature of ORMs make them amenable to the constructs most people use for manipulating queries with common web framework abstractions. In DRF, queries are separated by a base query, filtering by key, filtering by random acceptable criteria, pagination, etc. You just cannot separate the query components in SQL in a way that naturally maps to this abstraction. * Validating SQL syntax within an IDE that supports a host language is painful; validating chains of ORM events built in the host language is trivial. * Assigning behavior to resulting rows through objects in a ORM is, again, super trivial, while manipulating raw results in SQL to give them abstract behavior requires building your own intermediate layer. Why build something when it's already there and optimized for your use cases? * If you're building a library for common behavior that is database-agnostic, ORMs handle this well. You're not forced into learning the ins and outs of uncommon database engines.