Roadmap 2019, in which position is support for other QLs?


i know that you guys are familiar with your query language and questions about supporting others can be irritating :slight_smile: i know.

However it is a fact that people do not feel like learning other languages, and at the same time there is an issue of perceived safety when a DB claims to be supporting a “known” language.
Also it might be me but i find GraphQL+ pretty difficult to even understand for questions other than trivial entity lookups

It might be me but… :slight_smile: anyway. here is the question are languages like (better) or Gremlin realistically planned for 2019 and if so is there a ETA?

I get a great feeling from the dgraph technology but its hard to imagine using it without the"cozy feeling" that it supports languages which have been used successfully by others.

Thanks and have a great end of the year.

About the opencypher and Gremlin see last update about it Product Roadmap 2018 · Issue #1966 · dgraph-io/dgraph · GitHub

Bad idea IMO, but you guys must have your reasons. For me it makes it very difficult to consider as opposed to others which have either a standard syntax (cypher, gremlin or sparql) or a much more simple one (arangoDB and others)

i personally enjoy dgraph’s syntax. it’s more “webby”, and brings some fresh air to the graph database landscape. real graphql compliance is the right direction, IMHO :slight_smile:

1 Like

I think on a general level, the priority goes like this:

  • Official GraphQL spec.
  • Gremlin.
  • Cypher? / GQL? / SPARQL? – we’ll have to decide based on the adoption. Cypher, while popular, is still a niche language, and not a standard by any means. Neo4j is pushing for GQL, so by the time we support Gremlin, hopefully it is clear where do these cards fall.
1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.