Reading the comments I have a strong feeling that people here equate Active Record with ORM. There is another ORM pattern called Data Mapper: https://martinfowl

Reading the comments I have a strong feeling that people here equate Active Record with ORM. There is another ORM pattern called Data Mapper: https://martinfowler.com/eaaCatalog/dataMapper.html https://martinfowler.com/eaaCatalog/dataMapper.html I think that our goal as enterprise software developers is to automate business logic (business constraints) in a way that more-or-less a domain expert can read and understand. To create a precise language that facilitates fast and robust communication between experts and developers. New hire to the team should be able to learn domain expertise from the codebase because your codebase should contain easy to read domain model. Relational algebra and SQL is not a very expressive natural language. SQL limits your vocabulary to 4-5 verbs unless you start writing procedural code in procedures etc. but SQL is not a good procedural language. Relational databases are a solution to specific technical problems of execution speed, atomicity, consistency, isolation, and durability (ACID). They excel at that, not at communicating intention. You should use ORMs (preferably Data Mapper) if your goal is to solve the first problem while using off the shelf solution for the second problem. Data Mapper allows you to isolate your domain model from technical aspects of data storage. This will work very well as long as you will actually be able to ignore technical aspects in your domain model. You can do the data mapping, querying, migrations, and all this technical cruft manually with a handwritten SQL if you want, but SQL certainly will not address very well the first goal of creating an expressive domain model that facilitates robust communication between developers and business experts. And to address Active Record. It's a solution in the middle, you don't get full isolation, because database details creep into your model. The tight coupling of the domain model to ORM also makes it difficult to swap it for a handwritten mapper. But it's a very good tool for fast iteration and prototyping. And to address the only point from the article that is not moot based on my explanation above. "We can’t have nice things until we move our schemas out of our app languages and into declarative spec languages like SQL, proto, or even jsonschema / swagger (though I’m not a great fan of the last two)." SQL, jsonschema / swagger can't express business constraints. I'm working for a university. How do you express that "a student internship in some company A can not fall in time between some two other internships if the two other are in some company B" in a declarative non-domain specific language and make it still readable? You can write a declarative domain-specific language, but I wish you luck on your adventure trough parsers, interpreters, planners etc. to create that declarative domain-specific language in the first place.