&gt; SQL databases already have aggregation queries, so there&#x27;s nothing going on that they wouldn&#x27;t already do.<p>That&#x27;s true. I guess it depends on implementation. I was imagining something like CouchDB, which has to parse each document and run your map and reduce functions over them to build an index. Not something you&#x27;d want to do on-demand.<p>&gt; Having raw SQL in an application is insane.<p>That&#x27;s just like, your opinion man. We could argue all day on that one, but suffice it to say it&#x27;s definitely one of those Novice -&gt; Intermediate -&gt; Expert -&gt; Master circle-of-life things IME.<p>You can syntax check SQL. It&#x27;s easily understood by most developers regardless of background. You probably won&#x27;t have to spend more than 5 minutes getting up to speed with whatever driver you&#x27;re using. There&#x27;s never been an app that didn&#x27;t require major refactoring after swapping out the database layer. There&#x27;s just very little point in abstracting it IME. I&#x27;ve written a number of O&#x2F;R Mappers in my time, including creating the second most popular Ruby one.<p>I wouldn&#x27;t do it again. ;-) I&#x27;d use something like <a href="http:&#x2F;&#x2F;slick.typesafe.com&#x2F;doc&#x2F;3.1.1&#x2F;introduction.html#plain-sql-support" rel="nofollow">http:&#x2F;&#x2F;slick.typesafe.com&#x2F;doc&#x2F;3.1.1&#x2F;introduction.html#plain-...</a> write a few type-conversion protocols and call it a day. It&#x27;s safe, simple, productive and can be maintained by anyone. Any downsides are pretty minor IMO.<p>The comment on aesthetics is just that the primary interface to the database has a &quot;JavaScript First&quot; feel to it. It&#x27;s an odd choice (to me) to use a context bound Builder as opposed to an AST Builder you just pass to connection.execute or something.