Dgraph currently supports DQL (formerly named GraphQL±) and then can also generate a GraphQL endpoint. There has been much hadoop around the query language supported by Dgraph and part of the problem was that there was no single standard for a graph query language. Manish talked much about this in his introductions of Dgraph to the world.
But now it is April 2024, and there is finally a precedent of a standardized graph query language, GQL (not to be confused with GraphQL).
So the question I am asking, on everyone’s behalf, will there be any plan to support the GQL standard? I know I cannot ask is there any plan, because that can easily be answered, no. But I’m asking for a serious discussion from the entire Dgraph development team if you can decide whether or not Dgraph will support GQL in the future, and any thoughts and comments on GQL?
It’s definitely something we are aware of, and I certainly look forward to more input from the community on this.
Note that any hour spent working on GQL is an hour not spent on GraphQL, DQL, or other features, so community priorities are key.
I also note that GraphQL is a more widely used spec, and much more friendly to developers. IMO this is because both GraphQL and DQL are JSON technologies, and the queries very naturally represent the JSON return structures - they are self-descriptive and more trivially declarative in that sense. So we may want to lean into that differentiator, particularly now that LLMs make it much easier to migrate from cypher/GQL to DQL/GraphQL, reducing the need for exact compatibility.
Let me please remind you, that while GraphQL is more popular, it is not a Graph Query Language, but rather an API query language. This was proven when it was tried to be used for a pure database query language but it had to be extended into what DQL is today. GQL is meant to query a database, not an API. These conversations lead to questioning the same thing that always comes up, is Dgraph a database or just an API with the actual database features hidden away behind an API query language. Just things to consider for the future if Dgraph doesn’t turn into just a vector db for AI models to utilize.
That’s the exact same thought I have. I was considering DGraph the last few days, reading through all the historical documentation of the project itself. As I need a graph database for my new projects, I was considering DGraph as it seems promising. It has a great base to build on new features in the future (Edit: I don’t want to badmouth anyone here. What the development team has come up with is great and DGraph has a lot of potential. My comment here is not against anyone and is just my personal opinion on the subject)
However the used Graphql and DQL extension for querying seem a little bit unfinished for me, while the new vector support is implemented. Don’t get me wrong it seems necessary, as this implementation brings new investors and funds the project. However after reading through the historical decisions, provided by @amaster507 here
I’m not quite sure about the future of DGraph as a general graph database. The problem is, that in the earlier times, there were lots of good features in high priority, which were postponed due to newer ideas. But maybe this will change with the current state of the team.
Personally it would be great to hear that the DGraph would support standards like the GQL or would work on updating the already existing DQL language to support more analysis functions like Neo4j has with their data analysis package with numerous functions that play well together with cypher and let you do deep anaylsis alongside the graph. My opinion is that more and more graph database providers will implement support for GQL, now that it is a standard, so the idea is not that bad i think.
In the end there is the overall question, like amaster507 said, if DGraph plans to be a general Graph Database for any kind of graph application or if it drifts towards the ai scene and specifies on that topic considering their new vector implementation and becomming part of hypermode. This would neglect lots of other users that are using DGraph outside the ai sector. I think i have read a message from a team member, that DGraph will focus on the old stuff too, but however this is difficult to assess, considering that over the years many planned features have been left behind after new trends have emerged
I would like to also vote for supporting GQL/Cypher since a database based on a standard is a priority for us. dgraph with a standard query language like GQL will probably be the best database available for storing graph information.