Your argument is a variant of the object–relational impedance mismatch problem[1]. It's easier for us to reason about objects (or functions and types) than it i

Your argument is a variant of the object–relational impedance mismatch problem[1]. It's easier for us to reason about objects (or functions and types) than it is to think in terms of SQL tables, so it is much easier to develop complex logic or domain models in general purpose programming languages. Yet data storage and retrieval is much, much more efficient with relational databases, and it is generally a good practice to logically separate the data storage layer from the rest of the system anyway. But implementing that layer to translate from the relational model to the object model frequently involves tons of finicky, manually crafted SQL statements embedded in general purpose code where the linting/type checking/static analysis tooling often isn't great for the embedded SQL. The only other alternatives are using an ORM that automagically handles most if not all of the relational-object mapping or a NoSQL solution like Mongo that avoids the mismatch altogether. Both those alternatives typically involve sacrificing performance and scalability, however, and the limitations and quirks of each frequently contribute to bugs (e.g., schema drift in document DBs, or implementation details of the ORM that make it hard to map nested relationships). [1] https://en.wikipedia.org/wiki/Object%E2%80%93relational_impedance_mismatch https://en.wikipedia.org/wiki/Object%E2%80%93relational_impe...