Everything else is IMO a bad layer of abstraction that will eventually bite you when you need to get closer to SQL.
For Java based solutions, check out https://www.jooq.org/ or http://querydsl.com/
Honestly asking - I'm not an expert in this space: is this not just parameterized queries?
It seems like anything else would have to have exactly the same "shape" in order to support all underlying database features...
For example, if you’re adding filtering to a product list. The query will always return the product id, name, image url and description. But you might have multiple filters (in stock, blue, etc). The query builder can make that process easier and less error prone.
Same with pagination, depending on how you do it.
The query builder makes composable SQL syntax trees from raw text or Python objects. Executing those as queries gives you rows of tuples.
If you teach it the shapes of your data with the data mapper, you can query in terms of your tables (instead of ad-hoc column names) and get rows of populated custom objects.
On top of the mapper, the ORM defines your application-level data model, manages relationships and loading strategies, and powers up the query builder with the usual stuff like automatic joins (if you want them). You can still build composable queries, now against your application objects, but you can also work directly with the model like a standard ORM.
If you know you want the whole thing from the start, Declarative will let you do the mapping and the ORMing all at once by defining a class.
You just described ORMs. The implementation details can vary but ORM is pretty much an API for building queries on top of a DB.