Way I understand GraphQL is not as a replacement to SQL, otherwise you get hopelessly lost at implementing it.
It is in effect a filtering language. You have database view e.g. "user" and you apply it to the given GraphQL and get less fields than the view defined. In this way from server side you have still bunch of functions (the database views) that take in arguments (e.g. User ID) and GraphQL and the view returns the subset of the view.
Above is simple explanation I would try to implement GraphQL. Mutators are a different story I have not thought about.
That would be one way to implement the system in a DB-centric way. However we believe that intermediate application code is pretty critical to any GraphQL implementation.
We model mutations as a function that can do arbitrary business logic followed by a client-specified query where the client can query data it knows must be updated in order for the view to reflection the state changes the mutation caused.
It is in effect a filtering language. You have database view e.g. "user" and you apply it to the given GraphQL and get less fields than the view defined. In this way from server side you have still bunch of functions (the database views) that take in arguments (e.g. User ID) and GraphQL and the view returns the subset of the view.
Above is simple explanation I would try to implement GraphQL. Mutators are a different story I have not thought about.