The query optimization issue seems more to do with how the data is structured than perhaps the query engine? For example, if I wanted to query for all node type X, starting from node type A, it can potentially take a very very long time. But if I add a few known constraints like query all node type X, starting from node type A that paths through node B, C, D. It quickly gets much faster. I guess it's really more up the user to optimize the queries in these cases.

And the flexibility that graphdbs afford to the user makes it hard to realize that perhaps there are these natural constraints that can be used for this query. So it seems like there is definitely a graph analysis component to this that gives you the insight to write the queries faster.

I guess this problem also only applies to natural world problems that you are trying to force into a graph structure rather than a pre-designed database.

The goal of GQL is to gather a useful subset of your microservice data into a single tree for your frontend to render. In a facebook context, a typical query is "give me all the info i need to be able to show my home feed".

The goal of graph dbs is to allow arbitrary, complexm, often cyclic and aggregating queries to be run against a data source expressed as a graph. A typical query is something like "how many of my friend-of-friends like basketball, displayed by location."