There are three fairly independent points being made here: 1) ORMs (which are used in cases where you have control over the DB) are bad and you should just use

There are three fairly independent points being made here: 1) ORMs (which are used in cases where you have control over the DB) are bad and you should just use SQL 2) DSLs (in non-SQL DBs) are bad and the devs should have just exposed SQL 3) DSLs (in opaque services) are bad and the devs should have just exposed SQL I tend to agree with #1, though it's complicated and there's lots to be said on both sides. #2 seems semi-reasonable, if the semantics are close enough to those of a SQL DB, but the problem is that DBs like Mongo have wildly different semantics from SQL. #3 is harder because an opaque service usually specifically wants to insulate users from its implementation details. The great majority will not want to give you direct access to a SQL database. So the only alternative would be to "fake it" and pretty much base their DSL on SQL, which may or may not line up with the semantics of their service. For both #2 and #3, exposing SQL when the underlying semantics may or may not be a good match for the query language seems questionable at best. It encourages assumptions to be carried over that may not hold, especially around performance characteristics (which the OP specifically mentions as an advantage, surprisingly). I just don't see how this is tractable in the general case.