The real upside of GraphQL is that it has become popular enough that there are parsers in most languages, and that you don't waste time designing and testing a new standard. If you use it for a public API, you can also simply point people to the existing documentation.
It's definitely not a widely accepted standard, but still better than rolling your own!
You probably don't want to do that for security reasons. So either way you need a parser, and at that point, it makes sense to use something that is database agnostic and allows you to model relationships without complex joins or otherwise exposing the internal representation of the data.
http://githubengineering.com/the-github-graphql-api/
It's not really GraphQL vs SQL, it's GraphQL vs RESTful APIs.
In real life there will usually be a lot more going on to serve a GraphQL query than simply translating it to SQL.
The data you'll send might come from many different sources, including any kind of database, caches, or just constants in your code.
As commented here, permissions over data is a big topic, and if you were accepting raw SQL, you'd have to parse / tokenize it, and somehow validate it before executing it. This is what GraphQL does, but instead of trimming down and restricting the usage of SQL, it defines a language that is similar, close to being a subset of it, with a much simpler syntax.