I feel this is more a "classic" ORM problem. Wordpress is absolutely egregious here as well. I wrote up my strategy in another post, but I usually develop using

I feel this is more a "classic" ORM problem. Wordpress is absolutely egregious here as well. I wrote up my strategy in another post, but I usually develop using the ORM (often, ORM for writing, SQL builder + ORM for querying, because I hate ORM filter/join abstractions). I do think very hard up front what the product will require in terms of: - static content - dynamic content that is cacheable and which keys can be used to cache it Static content can use ORM as much as it wants, cloudfront will take care of it. dynamic content that is rarely hit doesn't really need much help either if there are no UX latency requirements. dynamic content that is hit very often (usually only a couple of endpoints) can be rewritten into manual SQL. If you think about it, most page hits with dynamic content can be rendered basically by the DB + templating engine, and no other logic should be involved.