What is Dgraph lacking?

I find this ironic. Dgraph brought GraphQL into the core because of the users demand for it. Go back and read old github issues, etc. This was done by bringing Michael Compton (and others) into Dgraph who had built exactly what you are referring to now outside of Dgraph. And now 2 years later users ask for this to go away back into the host it yourself graphql that connects to DQL.

I don’t believe this is the right direction but there is value here to your point. With other databases you can swap out the engine. What if dgraph handled GraphQL and other future languages such as Gremlin like extensions that could be added into the core?

This way a user who doesn’t want GraphQL doesn’t even get any of those endpoint because they didn’t install the GraphQL extension but they want Gremlin so they install that extension. And this I believe would open it up for more and more extensions to be added such as Graph Algorithms, or Cypher, or GQL (looks like it is becoming official spec)

Dgraph supports namespaces now.

I don’t think GraphQL is going anywhere. I just think it is for advanced real users. That being said, the trend has always been, and will always be, quick development with the least amount of effort (so we can concentrate on the product).

I believe that is why things like Supabase and Firebase are popular (and why they got backers). They work out-of-the-box with little to no knowledge and configuration. This is always the future.

That being said, they work on SQL and noSQL databases, not Graph. Whether or not it is DGraph, Graph Databases will catch on as the most powerful and intuitive, as soon as someone makes them easy and stream-lined.

DGraph is 80% of the way there, but needs to tighten up some things like the @auth directive, search features, and nested data relationships (filters, updates, and deletes).

That being said, we don’t know anything about the direction of DGraph, because there is unequivocally no communication from anyone about this. Hopefully it is the right direction for both our frontend developers, and our backend primary graph database users.



I do remember the time when it was added. You are right about that users asked for it but at least I wasn’t the one asking.
Maybe what users didn’t expect is that it with such a tight integration it would become claustrophobic.
I guess we should not listen to solutions proposed by users but only the problems they are facing.
That’s why I said I shouldn’t be giving out solutions but it was just faster that way. I could list the problems instead of solutions if you want.

Graphql may stick, and I would like it to but it’s certainly not fit in every situation and not the majority of developer. It’s a team thing so there’s high barrier of entry for graphql into stacks.
As you said graphql is loved only by advanced users and advanced users are much more likely to trade full freedom in customisation over magic that does things for them.
So tight integration of graphql serving might be hampering acceptance of dgraph. I don’t really know. You probably need a survey or something.

The majority of developers probably use a rest api, which graphql is a huge improvement on if you have relational data (especially with local caching etc).

I didn’t say only advanced users. In fact, I would say most real advanced users will write their own custom middleware (so quite the opposite), although one part of this middleware is probably in GraphQL.

This is just my opinion, but I don’t see how. You can easily use DQL without DGraph GraphQL. I think the majority of DGraph’s users don’t use the GraphQL middleware, but I have no idea as far as DGraph Cloud users, the paying users.

That being said, the product they’re selling is not solely a Graph Database. I agree with @CosmicPangolin1 that if they can’t support two eco-systems, they need to choose.

The people that use GraphQL don’t really care about GraphQL in-and-of-itself. They care about the middleware, which most DbaaS do NOT provide outside of the box (I spoke about this somewhere on here). GraphQL allows for caching on the front end, and is made for querying graph data.

Either way, the most important thing is that it is too costly to start all over at this point. They are 80% of the way there with GraphQL (it is probably impossible to get to 100%, but a few features we have listed can go a long way).


1 Like

There’s some misunderstanding here. By graphql I mean the original graphql spec. I use the term “graphql serving” for dgraph’s graphql.
The original topic of discussion was “what’s lacking” and not “what should we do”. I am just listing what I felt was lacking. I used “maybe” everywhere to make it clear that it’s just an idea in the air, I don’t really know about what direction should be taken.

No worries.

This was Manish’s original quote that started this thread. Without his input or any other Dgraph team member’s input, we are pretty much talking to ourselves for a month now. A lot of these topics, we just plain don’t have the information to understand.

I’m assuming the let's here is the inclusive we?

Perhaps we can actually get some input from the DGraph Team, or the Founder…?

Or at least a Roadmap…? News…? Updates…?

At the very least communication on when the next communication will be, lol (end of 2021) ?

“The single biggest problem in communication is the illusion that it has taken place.” - George Bernard Shaw


Sorry, I’ve been absent here – This thread blew up way more than I ever imagined. Clearly shows how much love there is for Dgraph in the community.

I’m working on a couple of blog posts for the release – once I publish at least one, I’ll read through this thread and opine.


Related: can we get @groupby(MONTH(creation_date))

see here: How to groupby date - #19 by geoyws
or here: Suggestions to Improve GroupBy - #6 by MichelDiz

1 Like

Just for reference this would be contingent on first having a month function for datetime. See Related Request:

DateTime Functions are needed

Exactly! the MONTH part was just an example for all kinds of datetime functions. Others are obviously: DAY, YEAR, HOUR. Just to make it possible to filter, group, and aggregate based on datetime.

FYK we already support group by scalar feat(DQL): @groupby on scalar fields and count duplicate by minhaj-shakeel · Pull Request #7746 · dgraph-io/dgraph · GitHub

That’s great. Now let us cast a datetime scalar as year, month, day, day of week etc. and then we get closer towards useful aggregations and summaries

This is a long thread guys – it would take me a while to read through this and grasp.

Meanwhile, Ask Dgraph Founder Anything.


That is THE question. As a competitor to Hasura / Tigergraph, Dgraph does not support many of the graph algorithms or Cypher, a language which would allow users to plug Dgraph instead of Neo4j.

As a GraphQL system, Dgraph provides facets, transactions, which are not so useful for GraphQL users. For this, Dgraph should aim for Firebase feature compatibility.

This makes me wonder if Dgraph should be forked into two directions – graph DB, where Cypher support is added, perhaps. And GraphQL system, which trades consistency for performance.


I’m not sure if this is a useful suggestion, but I run Firebase’s Firestore in production for a small, nonprofit application. Two well known limitations of Firestore are that it doesn’t support full text search and it doesn’t support relations/joins.

I was just reading Algolia’s docs to see how their search product works and I see it only supports full-text-search. It doesn’t support searching across relationships.

As a side product, it seems possible dgraph could offer an Algolia like SaaS offering that focuses on searching across relationships (and you could throw in the limited full text search capabilities that dgraph already has). Rather than a competitor to Firestore, this dgraph side product would be a compliment to Firestore and other services (I’m focusing on Firestore here because that’s what I’m familiar with, but I expect MongoDB and other products would similarly benefit).

A user could sync documents containing relationships to this new product and then search across those relationships. The user would then receive matched document IDs in the response, which they would use to find the original documents in Firestore (or whatever database they’re using) similar to how Algolia search works.

The primary theoretically difference between this product and dgraph itself is the scale/complexity. There would only be a SaaS offering (presumably built using dgraph the database) and every document uploaded would have all fields fully indexed by default. I imagine you could simplify the security model as well as, perhaps, discard real-time-updates and transactions since Firestore (i.e. the real database) would be providing those features itself and this would just be a serverless search/indexing tool.

It’s possible that this suggestion is basically a suggestion to create dgraph. After all, if Algolia supported relationships it’d basically be a database. But I imagine there’s a lot of features you could skip if you lean into the idea that your product will be a compliment to other products like Firestore. And then over time you could flesh out the features to make the product into a full database.

I say this as someone who tried Dgraph and found it to still be half baked (e.g. the graphql API doesn’t support nested filters but I expected that to have been part of the MVP).

Anyway, this feels like an off-the-wall suggestion but I was just reading the Algolia docs and thinking, “It would be great if there were a product like this for relationships…” Seems like such a product could be built on top of dgraph. Please no “DQL” though.


@thefliik - I have thought in detail about this. As a person who has built a medium-sized project in Firestore, and working on one in DGraph, I can tell you DGraph is more production ready by far than Firestore. I would not say the same thing about MongoDB, which seems to be production ready (even though I now hate noSQL). There are many situations you simply cannot even use increment / decrements in Firestore to use counters. Try building a follower feed with Firestore and Algolia. It is impossible, because neither of them allow joins.

That being said, DGraph is not 100%, but it is 90%. The extra 10% pretty much can be done with work arounds of Custom Lambda Mutations, and Custom DQL Queries. Firestore has no work-arounds.

I would argue to just switch your entire database to DGraph.

You can search on nested relations in DGraph, you just may have to currently build your own DQL Custom Queries.

Everything can be done in DGraph, you just may have to currently do a little bit more work than WHEN DGraph GraphQL gets more features.

Why manage 3 databases (or 2), when you can manage 1.



IMHO - I like DQL and instead of Cypher I would say for those of us really into data analytics what I miss most is their graph algorithms library… :slight_smile:


Enterprise Self Hosting should be cheaper and encouraged.(Right now, you are discouraging it). All enterprise customers are not always on AWS.
As the schema grows larger, Dgraph becomes slower.


I was looking for a GraphQL endpoint backed by a graph database and found Dgraph.

Looking at this very long and amazing thread it seems that there are two primary users:

  • developers looking for a robust and fast GraphQL endpoint with features that support a great developer experience
  • database specialists looking for a robust and fast graph database with features that support a great database management experience

Both of these groups are also looking for:

  • a serverless cloud experience
  • a self-hosted experience

There are probably a couple of other user categories that would really be interested in Dgraph:

  • no-code and low-code developers and platforms accessing a serverless cloud GraphQL endpoint
  • UI and UX designers looking for an effortless way to enhance their prototypes - which are getting more and more sophisticated and merging into no-code and low-code solutions
  • data analytics researchers

These last two groups are likely to use either Plugins available on their platforms, or go to an integration service like n8n.

What if Dgraph created, evolved and maintained a node designed to make it so easy to integrate with no-code and low-code platforms through another open-source integration platform like n8n?

Is there any reason why Dgraph cannot be a platform for both developers and database specialists?

Another consideration is to build on Dgraph’s developer features to also support a very compelling product for no-code and low-code builders. This kind of service could compete with RMDB based products like Xano:


Hello Nick!
I think dgraph will focus on the two first categories while the no-code low-code will be done by “intermediaries”. Dgraph should probably focus on its DB and its cloud service, the performance and DX, while an intermediary can focus on low-code prototyping and data-analysis

Here is a summary of dgraph key missing features and issues that @jdgamble555 and @amaster507 made:

At Blitz (YC S22) we are actually becoming one of those intermediasries for the other usr categories that you mention (https://www.blitznocode.com/)

We are building an abstraction layer over dgraph so non-developers can create a data model and pair it with workflows and an interface builder. With zero code! (It sounded like an Ad but is just me being hyped about by my own product lol)

So imagine a baby between xano/airtable + n8n/integromat + retool/stackr that a non-tech operations manager or entrepreneur can use to build tools or prototype new features.

I think that’s the right way to go, splitting the different types of customers with different types of products. So each one can focus on delivering the best value to their segment.

:memo: We are also developing a graphQL alternative (blitzQL) which works diretly in JSON format instead of strings, where we will be able to filter nodes by children props as well as editing children nodes from their parents, or cascade deletes. Eager to share more about this soon :wink: