Product Roadmap

[manishrjain]

• Low Latency
• High Throughput
• RDF Parsing
• Rocks DB Badger DB for persistence
• Commit Logs (Replaced by RAFT logs)
• Query Language - GraphQL-like
  • Query
  • Root Arguments
  • Fields
  • Response in JSON
  • Field Arguments
  • Field Alias
  • Mutations Mutations via GraphQL #23 [v0.2]
  • Fragments Support GraphQL Fragments #8
  • Variables
  • Type System
    • Scalar Types
    • Object Types
  • Mutation validation for scalar types
  • String matching / Name search
  • Sort by attribute
  • Limit number of results Limit number of results #9
  • Filter
    • anyof
    • allof
    • eq (equal)
    • inequality (>=, <=, >, <)
  • Aggregate Functions
    • count
    • sum
    • max
    • min
  • Geospatial Queries
    • Nearby
    • Within
    • Contains
    • Intersects
• Official Clients
  • Javascript
  • Go [v0.3]
  • Java
• Distributed Transactions
• Distributed Make DGraph distributed #14 [v0.2]
  • Distributed Loader [v0.2]
  • Distributed Server [v0.2]
• Clustering
  • Node discovery and membership via Dgraph Zero
• High Availability
  • Raft
  • Automatic Data Replication
  • Automatic Failover for reads
  • Read linearizability
• Resilience
  • Shard moves to handle server failure
• Export
• Backup

---

After v1.0 / Proprietary Plugins

• Multi-homing support
• Cypher Support
• Access Control Lists
• Query Graphical User Interface
• User authentication
• Cluster Management
• SPARQL [maybe]
• Tinkerpop Support [maybe]
• Distributed transactions [maybe]

[KyleAMathews]

It'd be cool if the DB could serve GraphiQL. This would be perfect for demos + internal spelunking through data.

[manishrjain]

I'm running a DGraph server holding Freebase Film data, which you can query like so: curl dgraph.xyz/query -XPOST -d '{}'. An example of the query is in the README.

[PhilAndrew]

Support tinkerpop? https://tinkerpop.apache.org

[manishrjain]

Tinkerpop would happen with Gremlin support. We'll do that after v1.0 gets released. This roadmap is largely focused on v1.0.

[F21]

For gossip discovery, I've found hashicorp/memberlist to work quite well.

[manishrjain]

@F21: Instead of using Gossip protocol, we used the already implemented RAFT protocol for keeping track of membership. In terms of discovery, our cluster requires knowing at least one node in the cluster; any healthy node would do.

[julsdelatierra]

I suggest also support cypher for queries, to avoid the queries migration from neo4j users.

[manishrjain]

@jcebXD -- Yeah, Cypher is something we'll fully support.

[pmualaba]

Cypher support will be great indeed for the application layer. I also see that Tinkerpop support is on the Roadmap after 1.0, but I would have prefered to see SPARQL instead. Since the data model for Dgraph is already Triple/Nquad based, it would be logic and convenient to expose a SPARQL 1.1 endpoint out of the box, in addition to the GraphQL endpoint. SPARQL support is very important to fully interact with the semantic web, without the need to take a full Dgraph (triples) backup which then again needs to be imported in a separate TripleStore such as BlazeGraph to be able to run SPARQL queries against the Dgraph data.

Is there any interest in supporting mobile ?
Running a dgrpah DB on mobiles using gomobile is possible. Even with the CGO aspect of rocksdb.
I currently run boltDB on the servers and the clients with golang. It is nice to have that reuse.

For example i build apps for mobile, desktop using golang with this: https://github.com/therecipe/qt
It uses CGO heavily, and works well.

[manishrjain]

@gedw99 -- We're not currently thinking about mobile. All our efforts are focused on production for large scale deployments.