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.
