Maybe that's a good reason to avoid GraphQL then?

That's not the reason, there are many but this a nice feature where a client can send one request and it will resolve internally (so less client side requests), you can request only the fields you need and it's easier when hitting multiple micro services.

Now you get into the issues of tracing, request failures and retries, payload size (only json? really..) etc.

But I do agree that a super optimized sql for a a specific purpose has it's performance benefit

In theory the graphql server could be smart enough to assemble a single SQL select to satisfy the query. Does anyone know of an implementation that does this?

If you're using GraphQL with SQL -- postgres specifically -- I would say use Hasura, but support between Hasura & CockroachDB seems to have stalled due to missing triggers [0] [1]. CRDB supports a feature called "changefeeds" [2] which is claimed might cover some of Hasura's use-cases, but that's a proprietary extension not present in base PostgreSQL.

[0]: https://github.com/hasura/graphql-engine/issues/678

[1]: https://github.com/cockroachdb/cockroach/issues/28296

[2]: https://www.cockroachlabs.com/docs/v21.1/stream-data-out-of-...

Any views on which to choose between Prisma, Hasura or postgraphile for GraphQL and postgres?