If you're proposing that web servers should not exist and we should just expose the SQL DB via HTTP: what about when you don't have all of your data in a single database?
What if I want/need Cassandra, ElasticSearch or MongoDB? An SQL DB is just one place where you have data and there are very valid reasons for using other solutions.
In fact, some people might argue that you want to do everything with event sourcing / kappa and use Kafka + specialised data stores.
GraphQL fits this universe perfectly. It also fits the one where you only use a single SQL DB since a GraphQL query translates quite nicely to SQL with minimal amount of code in between.
One immediate improvement: SQL queries return rows of scalars. It's very tedious to reconstruct nested objects from the resulting column aliases that are ultimately necessary (and in this case, the client would even need to do it all themselves!). Your example is simplistic in that it requests one top-level scalar, but any real API will not be like that. Try:
{
project(name: "GraphQL") {
tagline
authors {
name
friends {
name
}
}
}
}
I've used its JSON support extensively and no, it's not really the same at all. What you're saying is that you're OK with (1) planning to not use columns to store your individual data fields in the first place, forgoing the primary SQL features of column-based lookup, joins, etc., or (2) having the client write complicated Postgres-specific SQL queries that dynamically construct JSON strings built from the fields that are stored in the real row structure.
That real answer to the parent's question is that most people don't have confidence in SQL servers's access controls.