SqlKata Query Builder VS iterlib

SqlKata is your friend.

Don't know if can be a good pick for the no-ORM requirement but I would take a look at SqlKata which is a nice query builder + execution engine, built on top of Dapper

Not really an ORM. But I have been enjoying SqlKata recently. Works with Dapper but helps reduce SQL strings and makes things like pagination really easy. Also nice for dynamic filters.

That is basically the description of an object mapper, with all the guarantees of an object mapper :). It seems if you actually use the query builder as such, no guarantees exist.

I'm pretty picky regarding query builders and ORM's, to the extent of having written several of them over the years, in different languages (both dynamic and strong typed, unfortunately closed-source). I'm a strong advocate of schema-first design, and usually a query builder will allow you to design your queries explicitly, but having some internal behaviors (such as string concatenation, identifier quoting and automatic in-order separation of parameters and values to be bound) taken care of. As good examples of this, I'd mention golang's goqu (https://github.com/doug-martin/goqu) and - to some extent - C# SqlKata (https://sqlkata.com/). Following my frustrations with Python ORMs, I built my own toy project, sort-of-in-beta, called rickdb (https://github.com/oddbit-project/rick_db).

Less about the exact syntax and more about the tool, for example: https://github.com/sqlkata/querybuilder. I just chose that since it was on top of a search but the idea is the same. Your code generates raw SQL, so it's 100% interchangeable with writing SQL yourself however the builder library deals with the syntax, proper ordering, quoting, full attribute names, etc. Some such libraries even let you define your schema in code to make your SQL generation type safe.

I wrote such a C++ implementation during my days at Facebook around 8 years ago:

https://engineering.fb.com/2016/03/18/data-infrastructure/dr...

There is an example under "Functional programming primitives".

It was a C++ implementation that fell victim to Greenspun's 10th rule. So I wrote a specification for it, first in Clojure and then in python.

The C++ execution engine is open source:

https://github.com/facebookarchive/iterlib/

Main problems writing such code:

* The output of SQL is generally flat. GraphQL makes it nested, but doesn't support all the operators SQL does natively.