My name is Akon Dey. I have joined Dgraph Labs, Inc. as the interim CEO and VP of Engineering. I have a background in enterprise databases and very large scale distributed data systems. Over the last 25 years, I built a number of systems to solve hard data and database related problems.
It is exciting to see such an active and vibrant community of users and loyal customers.
I am convinced that distributed graph database technology will make a significant impact on the applications of the future. I am looking forward to helping the company take this technology further. I intend to apply my background and experience to build upon the current Dgraph offerings to make them even more reliable, scalable and efficient to solve the needs of our community and customers.
We will continue supporting the product and providing the best service we can to ensure the success of our stakeholders who are depending on Dgraph Labs.
As we speak, we are in the process of finalizing funding from both new and existing investors.
We have been able to retain a number of people from the original team to help us continue to serve our customers and user community and to rebuild the team. A number of people with experience in building database systems will be joining the team in the coming weeks.
I am glad to note that a number of contributors who have moved on from Dgraph Labs will be forking and/or contributing to Dgraph Labs’ public repositories. We are exploring ways in which we can continue to collaborate for the benefit of both the developer community and customers.
I am optimistic about the future of the company and request your patience and support as we rebuild the team. I will be using this forum to keep you informed about the progress we make and look forward to working with all of you to take Dgraph forward.
It is reassuring to hear this. I hope you are able to keep in mind that communication from the team (or lack thereof) has been one of the most frustrating aspects of Dgraph in the past. I know people here are eager for that to change, and I hope this is the beginning of a new era in that respect. I wish you and the team the best of luck with moving forward through all these changes.
Thank you for coming forward and clarifying the situation. That said, from a users perspective. I would like to outline what I would wish for the next 12 months of your tenure.
The last stable release of Dgraph was v21.03.2. Subsequent versions each have their own issues. The first priority of the team is to go through the forums and fix issues pertaining to ingesting data at high scales, node loss and handling more than a million nodes. What concerns a lot of us in the community was the rushed version “Zion” which tarnished Dgraph as it’s not a stable release. So the first order of business is to connect with the community, find what issues need resolving as a baseline and release a new v22.00 (stable) version.
A roadmap is another priority. The community hasn’t seen any meaningful progress in the last year. It would put a lot of us at ease who has chosen Dgraph to be at the center of our infrastructure. This forum should be treated as a goldmine of information. At a minimum a similar roadmap to that of Prisma 0 needs to be made available and kept up to date. If a quarterly push was made and what features per quarter are scheduled to be shipped, this would energise the community so much more.
Regarding point 1 and 2. If you need specific help in pin-pointing these issues. I’m sure a few of us in the discord can get together and create a document for you.
The current implementation of GraphQL is not fit for purpose. It needs to be ripped out and replaced with the latest specification and fully working. Additionally, in development and once released it has to be tested by the community. It is clear with an outsiders perspective that the documentation is very bad, none of the previous developers dogfooded any previous releases. If they did the current crop of issues simply would not exist. Therefore, it’s clear Dgraph needs help with polish. It seemed to me that there was a clear substandard of work being allowed and this lead to issues with the website, documentation, releases and recently even cloud stability. This needs to be resolved at a high priority. Now that there is new CEO and new team, you have the ability to fix any and all issues.
The secret sauce of Dgraph is DQL. This is what Dgraph should be expanding upon. To code any compatibility layers for Gremlin or Cypher should be ruled out and in my opinion is a waste of developer time. Moreover, the following functionality should be added at a minimum 1. DQL will differentiate your product from competitors and help you to take on Neo4j. This is another high priority.
The Enterprise license needs to go. Open up all the enterprise features and fold them into open source. Companies like Singlestore 2 allow companies to run 3 nodes up to 128gb of ram. This allows solo-devs and startups to get to a point where they require paid support. Have an ability to offer paid support. Many companies want to run in environments that are not the cloud.
A query planner is desperately needed. At scale, especially with legislation such as the GDPR and CCPA. Soft deletes are invaluable. At scale the performance of Dgraph doubles the read operation when filtering out deleted items. A query planner would fix this and generally improve the performance depending on what is being requested.
There is a lot more, but resolving these issues will get you and the community to be in a better place and better positioned to take on the future.
Welcome!! Very pleasant welcoming (and also very positive news youve mentioned) and a big reassurance that the new CEO is also an engineer himself!
I agree with everything that @Paul said! For me as a junior developer the docs were the only hard thing of dgraph, and understanding what dgraph even exactly is, fortunately the big awesome community and previous CEO explained me very well what Dgraph is, how freaking awesome it is, and helped me with learning and schema design! So working on the docs would 101% help to onboard more users who are interested in dgraph.
Please join our Discord, it would be very cool if you would also have some kind of direct contact with us the community
I agree in general and COMPLETELY agree regarding you DQL point.
DQL is so powerful and I honestly found it extremely frustrating even with the emphasis on graphql over the last year especially with the painful way the two schemas interact.
We have DGraph operating as the main DB for 2 pretty hot startups at the moment and we do everything with DQL.
Looking forward to future updates and communication.
This is great news! Already said this on Discord, but congrats on your new role at Dgraph Labs! Excited to see a team coming together.
Just to throw in my two cents… I’ve been saying for a long time that Dgraph Labs has been trying to work on too many goals at once. The features and bug fixes have been haphazard, and it’s never been clear how things are prioritised.
Personally what I need is a versatile GraphQL API so I can avoid having to create custom endpoints or custom resolvers as much as possible (and therefore ship product faster). What originally drew me to Dgraph was the combination of a powerful graph database layer and a GraphQL API. My hope is that eventually Dgraph will add graph algorithms and more advanced DQL querying functionality so I can extract a diverse array of ML features for an ML pipeline.
So in summary I hope to see Dgraph Labs continue to iterate on DQL moving towards becoming competitive with Neo4j and also continue to iterate on GraphQL moving towards becoming competitive with Hasura. I think what is crucial for Labs is that they start measuring demand for functionality and features through community engagement and voting. This forum hasn’t been a good place for that IMO. What Labs needs is to allow users to vote on what the team works on via something like Canny or one of its alternatives. There’s a whole bunch of stuff on the roadmap (if you can find it!) that I really question the necessity of. For example, things like Kafka integration—why should this have been a priority when there are serious security flaws that haven’t been resolved?
Perhaps the solution to this is for Labs and Outcaste to collaborate, with Labs focussing on making the DQL layer competitive with Neo4j + providing a hosting solution and Outcaste focussing on shipping new GraphQL features. Although, I’m not super optimistic about that.
Anyway, hope that’s useful. Good luck to you and the new team and I hope to see you all in Discord.
Thank you for the detailed post. Let us use this forum to define the product and prioritize features. The team’s immediate focus will be security, stability, availability, operability and the other ilities. However, as the team grows and matures we will begin prioritizing new features. I don’t have a timeline for this yet but I would like us to get there soon. I expect that some of the issues such as those related to security and documentation problems would be addressed sooner.
While I request you to be patient while the dust settles, I do not want to give you an impression that we are going to ignore feature requests. We will explore creative ways to satisfy end user requirements. I have a few ideas on how we can achieve this and will share them after exploring their feasibility. I may reach out to some of you over the coming weeks to get your input as well.
In the meantime, thank you for your inputs and your continued support. I am looking forward to working with you.
@BenW I will stay in touch with you and reach out for a more detailed conversation soon. Some of your requests are interesting but require significant engineering commitment. Let us work together to figure out what might be a suitable roadmap to get you what you need.
Thanks for the feedback. We have discussed the communication issues within the team and have a plan to address them. Please continue to provide the feedback over the next few weeks until we get it to where it’s right.
@akon PLEASE layer5+ anti ddos protection for graphql/dql auth endpoints, AND for the subscription feature!! the subscription feature is AMAZING and helps building apps with realtime reactiveness like discourse discord facebook, and reddit introduced lately, we really need that subscription feature, and adequate auth capabilities + ddos protection! especially for that subscription feature! Since the client is connected directly to the subscription websocket, and we can’t install unnecessary intermediate servers between them just for auth and ddos protection (ok it would be possible to build an elixier server as an intermediate, but that would be an overkill)
you could maybe also collab with cloudflare as discord did
we need Layer 5+ DDoS protection for endpoints, and the subscription websocket, and the new graphql-ws websocket
Out of the box easy to configure ddos protection would be really cool.
If we want to build on dgraph the next facebook discord tiktok, we need safe realtime features!
I would also suggest for dgraph to collab with cloudflare like the competition did! cloudflare is an amazing company and helps us all, i think most of us use them. I also designed to use Cloudflare Workers as an intermediate between the client and dgraph. For doing sanitization, spam checking, IP checking, firebase auth checking, inserting new data also immediately into typesense cloud, and so on. since I don’t expose the DQL and GraphQL endpoints publically (also because of no ddos protection.)
