I remember seeing graphql-jit on a comparative benchmark of GQL server implementations, and it blowing everything out of the water, really impressive: https://

I remember seeing graphql-jit on a comparative benchmark of GQL server implementations, and it blowing everything out of the water, really impressive: https://github.com/benawad/node-graphql-benchmarks https://github.com/benawad/node-graphql-benchmarks Depending on your usecase, you can go one level further and directly evaluate the query AST without delegating to resolvers. (This generally only makes sense if you do programmatic schema generation. IE, read some metadata about a source and then generate GQL types/operations from it.) So a query comes in, say something like: query { users(where: { name: { like: "foo" } }) { id email todos(where: { completed: { eq: true } }) { description } } } Rather than having resolvers, and firing the "users" and "users.todos" resolvers, you interpret the AST of the query directly as if it were a regular value In the case of a SQL database, you'd have a recursive function that takes a level of the query AST and generates a SQL string. Then you'd execute the query, format the results, and return it to the client. IE, in this case you'd probably generate something like SELECT id, email, JSON_OBJECT('todos', ...) AS todos FROM users JOIN todos ON todos.user_id = users.id As far as the client can tell, it's a "regular" GraphQL server, but the serverside implementation doesn't have any kind of real executable schema. It just behaves like it does. The downside of this approach is that you lose the ability to use built-in functionality for things like tracing, query depth/complexity limiting, etc. You'd have to write this on your own.