Product Roadmap 2020

[manishrjain]

Here's the product roadmap for 2020.

• Official GraphQL spec compliance
  • Queries (Q1)
  • Mutations (Q1)
  • Subscriptions (Q2)
  • Live Queries (Q2)
• SaaS (Q2)
• Scalability, performance, and reliability
  • Single predicate sharded across groups (TBD)
  • Distributed bulk loader (Q3)
  • Rolling upgrades (Q4)
  • Ludicrous mode (Q1)
  • Query Planner (TBD)
• Enterprise features
  • Change Data Capture (Q3)
  • Multi-tenancy (Q3)
  • Point-in-time recovery (TBD)
  • Audit logs (Q3)
  • ACL integration with AD, LDAP (stretch goal)
• Integrations
  • Kubernetes
    • Operator (TBD)
    • Bulk Loader (TBD)
  • Kafka (TBD)
  • Others. Let us know in comments.

We have mentioned the features we are planning to focus on in Q1 and Q2 (first half of 2020). For the rest, we'll assess them for their ETA as reach mid-year. Tell us what more you'd like to see happen in 2020!

[manishrjain]

I know a bunch of folks have been looking for Gremlin support. We're currently focused on GraphQL, but if you need Gremlin to work with Dgraph, show your support by upvoting this comment and we'll consider prioritizing it in a few months.

[smkhalsa]

@manishrjain Thanks for the update and for the wonderful work you and the dgraph team are doing.

I'm glad to see that a fully managed SaaS option is on the roadmap.

One question: I don't see any specific mention of exposing full GraphQL+- functionality in spec-compliant GraphQL queries (something like what neo4j-graphql-js offers). There was an indication from the dgraph team shortly after the graphql api was launched that this was coming soon. If that's the case, can you give a preview of how that might work?

[manishrjain]

exposing full GraphQL+- functionality in spec-compliant GraphQL queries

We're considering multiple ways of doing this:

1. Figuring out ways in which we can port over +- functionality in GraphQL spec compliant way, so a GraphQL user can just construct these queries directly (fuzzy matching, full-text search, has function).

2. Adding automatically generated GraphQL functions for the complex +- functionality (like, say email: string @index(exact) @upsert could have upsertEmail func automatically generated).

3. If a feature can't be translated into GraphQL, then having a way for a user to specify a function name along with the +- query it maps to. This is the closest to the resolver pattern exposed via Apollo. This would be done at schema level, instead of involving any particular programming language (Apollo's resolvers are typically javascript based) for maximizing compatibility among various languages.

For now, we're going with easy wins, that is 1 and 2. Once we have covered and exhausted ways to port +- into 1 or 2, we can look into 3.

[vikram-ma]

@manishrjain
Where can I find more details to understand what these goals really mean?

• For example, what does "Ludicrous mode (TBD)" do? and what's the plan to achieve this is.
• Also can you elaborate Query Planner (TBD)?
  Do you guys have any checks in place to control GraphQL (and graphql+-) query complexity? To prevent friendly fire scenario? Will this be part of Query Planner?

[Relaxe111]

Hello, it looks like multi-tenancy support is added to Enterprise feature. I would kindly ask to reconsider this feature to make it open source or to make a more flexible pricing plan. Locking this feature in Enterprise version could be a big barrier in widely adoptoption of dgraph, at least in the EU it will be for sure.

[manishrjain]

All the enterprise features (including multi-tenancy) would be automatically included in the SaaS offering. That should allow for flexible, pay as you go sort of pricing.

Ludicrous mode -- Idea is to allow a mode of Dgraph, which gives up on some "correctness" things to achieve maximum performance. For a lot of people, if Dgraph doesn't give them the needed speed, they revert to a NoSQL database, which provide you very little in terms of consistency / transactional guarantees. This mode would allow Dgraph to run with lower guarantees, but at a faster speed.

Query Planner: Dgraph doesn't do much query planning right now. It executes the queries in the same order they're given. Of course, we could do a better job by having an internal query planner which can alter the ordering of tasks to achieve better performance.

Do you guys have any checks in place to control GraphQL (and graphql+-) query complexity

Not sure what you mean.

[vikram-ma]

Clients can do arbitrarily complex GraphQL queries.i.e clients control it the query complexity.
What it means is that clients can issue very very complex queries i.e queries could take minutes/hours to complete, and impact dgraph's ability to serve other requests.

A valid client is making very complex query, that significantly slows down or impacts dgraph's ability to serve other client requests.

Are there checks in place to detect/prevent/handle this?

[willem520]

Hello, it looks like multi-tenancy support is added to Enterprise feature. I would kindly ask to reconsider this feature to make it open source or to make a more flexible pricing plan. Locking this feature in Enterprise version could be a big barrier in widely adoptoption of dgraph, at least in the EU it will be for sure.

hi, multi-tenancy is a popular feature, many developer like us need this feature to improve our project. Personally, I hope it could be free. thx

[manishrjain]

Are there checks in place to detect/prevent/handle this?

A client can specify a context with timeout, which can shut the query down once if it runs too long. But, apart from that, nothing avoids that right now. Once we have a query planner and can calculate the cost of running a query, we can do a better job of rejecting expensive queries.

[nmabhinandan]

• A startup program offering evaluation license of enterprise edition. (or better yet, SaaS credits).
• A reactive Spring Data client (Along the lines of SDN/RX)
• GeoJson support

[manishrjain]

A startup program offering evaluation license of enterprise edition. (or better yet, SaaS credits).

Already there. Every Dgraph instance comes with a month of free enterprise trial.

GeoJson support

Already there. Dgraph has been supporting geo queries since the early days. In fact, some users have said that Dgraph's geo support is better than PostGis (we haven't verified).

[Relaxe111]

Saas including multi-tenancy I think is not what majority of developers will really searching for. I mean by more flexible pricing plan to make gradual licencing. For example a company could choose and pay only for Enterprise feature in which is interested, if I need only one feature I would not be happy to pay full license but using only one feature.