Beyond ORMs

Not gonna argue on the decade old "ORMs are bad" part, to each their own, but:

Another missing feature in ORMs is the ability to use prepared statements.

Not sure what this is about, both Active Record and Sequel support prepared statements.

The article treats “ORM” and ActiveRecord as interchangeable, and that's doing most of the work here. Ruby doesn't really have a session- or value-based ORM to compare against (Sequel exists, but the author abandoned it too), so the specific design choices ActiveRecord made read as inherent to ORMs in general.

In Passing interfaces around, Post.where(...) can be called from a view template because Post is a global constant with an implicit connection behind it, not because it maps rows to objects. SQLAlchemy's Session is a value you pass around; nothing about mapping tables to classes forces the connection itself into global state. The PostsStore pattern the piece lands on is, structurally, a Session with one table's worth of methods on it. I'd call that an argument against ActiveRecord's connection handling, not against ORMs as such.

Same thing with the DSL argument. “SQL knowledge isn't optional, so we don't need a DSL” and “queries are finite, so a general purpose DSL is wasted effort” get treated as one argument, but they're not. SQLAlchemy Core is a DSL that assumes you already know SQL: it's there so you can compose query fragments as values, conditionally add a join, reuse a subquery, not to hide SQL from you. I care more about whether queries need to compose, say to support user-selected filters and sort order, than how many total query shapes an app has. The PostsStore examples in the piece are all fixed-shape, parameterized-only queries. I don't see what query composition would buy those examples.