On GraphQL-to-SQL

6 min readMay 21, 2020

GraphQL has a reputation for its N+1 problem which can often happen when implemented naively. This leads to a lot of us trying to solve the issue of data fetching with GraphQL in the most efficient way possible. Besides the popular Dataloader approach, another very common way of tackling this problem is by taking a GraphQL query, and coming up with the exact SQL needed to resolve it:

// example from Join Monster
{                           SELECT                  
  user(id: 1) {               "user"."id",          
    idEncoded                 "user"."first_name",  
    fullName        ==>       "user"."last_name",    
    email                     "user"."email_address"
  }                         FROM "accounts" AS "user"
}                           WHERE "user"."id" = 1

Looking at this query, this is the absolute most efficient way of getting the data for it. This is a really interesting idea, and it’s not surprising many people are aiming for something like this 👇

Join Monster was one of the original tools doing this
Hasura has a powerful GraphQL to SQL engine based on PostgreSQL and compiles GraphQL queries into a SQL statement
PostGraphile “compiles a query tree of any depth into a single SQL statement, resulting in extremely efficient execution”
SqlMancer
Super Graph
GraphQL Compiler
I’m sure I’m forgetting others!

All these tools are slightly different and the core problem they solve is not all the same. However, they all rely a lot on compiling a GraphQL AST into a SQL statement that will hopefully be more performant than the combined SQL statements that would be executed from a naive GraphQL implementation.

I see a lot of effort towards those tools, but they never really seemed to be able to solve the GraphQL data fetching issues I see day-to-day.

Some are tied to a particular style of development

Hasura and PostGraphile are really solid products, and are different from just a GraphQL-to-SQL in the sense that they aim to be a complete solution for building applications. In both these tools the database is what drives a lot of the application…