[slver]

Technically it is. But in a very restricted way.

Any graph, when you traverse it from a specific node, with fixed depth, and you don't explicitly work with node references, but rather node "values", looks like a tree that sprawls from that node.

Anyway, PathQuery is a completely different beast regardless.

[contravariant]

If that counts as querying a graph then SQL is also a graph language. If anything SQL is more advanced because it can query a hypergraph.

[slver]

SQL is neither a graph or hypergraph query language, because relations don't define the graph (or hypergraph). The query does. Deriving a graph and querying a graph are two different things.

A graph query language implies you're querying a graph with specific edges, not ones constructed on the fly from the query.

GraphQL's goal isn't to be "advanced" either. Its goal is to allow access to any data structure (be it backed by graph, RDBMS, file system, NoSQL, etc. etc.) without burdening said structure with capabilities that are not characteristic to it.

Like, if you query a graph, the idea the query may provide any arbitrary join expression would completely drive that graph's performance into the ground.

[contravariant]

I can get behind the idea that SQL is a bit too powerful to allow it to talk to other databases easily.

And not automatically joining by foreign key is a mistake that's going to haunt us for a while I bet.

However when we're arguing capability then it's just as capable of querying a graph as graphDB is. More if the version of SQL supports recursive joins.

[slver]

The thing I can't seem to get across to you, is that you don't query a graph by specifying a join expression. Graph databases aren't built for that. So no, SQL is not "capable of querying a graph". It's capable of deriving a graph out of relational data. Two completely different things. It's a bit like confusing a restaurant's chef with the restaurant's customer. They both have a meal in common, but one is consuming what the other is producing.

And no, arbitrary join expressions are not a feature that "haunts" SQL databases, because unlike graph databases, relational databases ARE built for that, and it's one of the primary reasons SQL databases are very resilient to change in face of constantly changing ad-hoc query requirements. And it's an important feature of relational algebra that is used every day by countless applications.

SQL and GraphQL serve different purposes at different application layers. Both do precisely what they have to do. The fact they're a bit similar is not coincidental, but also they're not mutually replaceable.