Q1 Update from Dgraph HQ

It’s officially Q3, and it is hard to know if Dgraph even is alive.

Nobody has done any PRs for years (outside of a few small ones that weren’t included in the v23 fork).

Why would they for a dead product? Think about this.

Could you guys just admit:

  1. No new enhancements are coming outside of Vector support. DQL will not get constraints, cascade fixes, nor loops.
  2. The GraphQL will not get the security fixes repaired, and there will not be a work-around with triggers, nested mutations, nor sort by nested aggregations etc.
  3. None of the thousands of hours spent by actual users explaining the problems will be taken into account to fix any other problems or feature requests.

If I’m wrong, please correct me.



Hi @jdgamble555,

The headline is: we’re a small team doing our best to continue to improve and maintain a project that’s been loved/used by so many for so many years. I understand ya’ll would like to see more/faster from us-- honestly, so would we.

That said, with that small team we’ve got, we’re balancing adding more Global 2000 customers and their specific requirements (We grew revenue by 50% QoQ!) vs contributing things back to this community. The upside for you all is that the more customers we’re able to make successful, the more engineering capacity we’ll be able to subsidize for Dgraph’s open source projects.

In Q2 we shipped:

Vector Support

  • shipped alpha, RC, and GA builds with community participation
  • seeing strong interest in this functionality

Maintenance and Performance Updates

  • v24 brings 32% improvement in writes
  • v24 brings up to 1000x improvement in reads for customers with complex GraphQL schemas
  • v24 brought a major upgrade to Golang v1.22

Embrace External Contributions

  • v24 included 89 commits from 24 different contributors

We’ve put a focus on test speed and flakiness to shorten response times; more work to do but over the last 60 days:

  • run time is down 86%
  • failure rate is down 30%

We’ve heard resounding feedback from the community about the importance of the maintenance investments and intend to continue focusing there, notably:

  • further investment in testing
  • refactoring around complex and outdated components
  • updating all Dgraph clients

We’re cooking as fast as we can!


Honest question, how many of these are old commits that were re-merged?

This is not balancing when there are no contributions outside of maintenance. There are security bugs that need to be fixed, which should be included in maintenance.

Adding even one feature the PSC team has requested would go a long way. Otherwise, you’re not showing you care what your current users want. You still have enterprise users that need things done.

This is extremely important, and without a doubt first priority. Maintenance should not be the only priority.

You basically do NOT have a plan to do anything outside of maintenance and “grow the business.”

Got it.

The team I work with uses the java client (GitHub - dgraph-io/dgraph4j: Official Dgraph Java client). I’m interested to see what improvements the team is cooking up there.

1 Like

Anything specific features or fixes you and your team would like to see?

@KVG - Could I ask where you guys see this company going, do you have a mission statement, a long term plan?

What is Dgraph to you guys, and what are you planning on doing with it?

I think we could use some clarity on this.



Two areas of focus that have stumped us are:

  1. Exception handling - more granular exceptions would be great, we end up parsing strings out of generic expectation messages to see what kind of exception it is.
  2. Chunking - we’ve had to write a lot of not-great code to get below the 4mb grpc limit with chunking. It’d be great if the client handled this transparently.
1 Like

congrats! that’s fantastic!

1 Like

@rft :point_up:

1 Like

Hey @rahst12,
Thank you for your feedback. We appreciate your suggestion for more granular exceptions. Could you please elaborate on your use case so we can get an idea of what kind of improvements we can make?

Regarding chunking, could you please share your code snippet with us? It would help us understand your approach better and inspire potential solutions.