Yep, GraphQL is agnostic as to how your data is stored. For example, https://github.com/graphql/swapi-graphql/ is a GraphQL schema that is backed by the swapi.co API. The examples at https://github.com/graphql/graphql-js/blob/master/src/__test... are backed by in-memory JSON objects. At Facebook, we have GraphQL types backed by data stored in a number of backends, including types backed by SQL tables.

I'd like to read more about the backing data stores. If you're aggregating data across a lot of different stores, it seems you could easily add what looks like a tiny piece of data to your query, but, in truth, is much more expensive on the backend.

It's important to realize that you're essentially defining an API for your product. If something is expensive to access, you should either not expose it directly through your API, or add appropriate levels of caching to mitigate the costs.

Even if your data isn't stored in a graph, it can be queried hierarchically, like a graph. Hence the name, GraphQL (as opposed to GraphDB).

It seems that the graph part is referring to how the input is evaluated one node at a time and applied to the output. The sub objects (child nodes) of the input are evaluated and then applied to the output. It's a graph in the sense that it's a tree being evaluated and built. I would think it's pretty optimal if you're using nosql stores that are cached heavily with good locality of data and you can send the request to the right server based on the first node of the input.

It's not about graph databases but it is about graph data.

But at the end of the day, most data can be considered graph data. It doesn't have to be represented as a formal graph.