I can't talk about PostGraphile, but that's my experience using anything automated. Even your run of the mill ORM's drive me nuts. Abstracting out schemas is fine, but when it comes to query creation, I need to be in COMPLETE control of what is happening.

with PostGraphile you pretty much are in complete control. You're free to write your own postgres functions/views which postgraphile will expose as endpoints. you can do so such that they are standalone endpoints or sub-queries to the auto-generated table queries. you can also basically bypass all the auto-generated table queries by creating them in a schema that postgraphile doesn't introspect, and then write all the functionality you want in a schema that it will, thus getting only endpoints/queries that you wrote yourself exposed in the api.

This isn't an ORM, is it? I poked at it in an earlier (PostGraphQL) version and it feels like a query translator from GraphQL to SQL and back, to me, with no munging onto or into objects, at all. ORMs are for people who love their programming language but don't want to touch the database.

This is kinda the opposite of an ORM. Nearly everything is in the database and this is a wrapper that allows you to build your app in your database.

You're thinking of code-first ORMs (to use the EF terminology), where you write classes and the tool maps them to tables and queries.

These GraphQL tools, however, act a lot like a database-first ORM, where you provide a database and the tool generates code in a different paradigm (OO for ORMs, Graph QL here). It is indeed the opposite direction, but ORMs can work that way too.

Yeah, I guess GraphQL is delivering JSON "objects". Nonetheless, developing for it is a completely different experience from any other ORM I've ever poked at (not saying it's better, just very different).