We don’t know. And we’re not in a position to make a plan for the future.
Pre-June I wouldn’t say that – we had 3 teams (cloud, GraphQL and core), a solid TPM who was ensuring delivery of features and so on. We built a lot during the first two quarters (Multi-tenancy, CDC, Audit Logs, Kafka, launching MT in cloud, Sroar, etc.), including a complete overhaul of the cloud. But, post June, I know you guys have been vocal about what you want – we just didn’t have the resources to do much. Out of a team of 50, we had about 15 remaining (nicknamed Zion internally) – with the focus on making the business profitable and raising funds. And dealing with the company politics, which is a full time job in itself.
Anyways, from a users’ perspective – our velocity of feature development slowed down. And that’s visible, I get that. But, not because we don’t care about the users. That’s just because we have been trying hard to keep the boat afloat – and get the Zion release out.
As I have said many times, the lack of communication has been the number one problem, not the lack of features.
I would think getting it on the Cloud would be the number one thing the board would want.
If you have the power to get issues (and hopefully features) put on Github, I would think you could let them know you need a roadmap too. That pretty much would solve MOST of my issues, and many others. Again, if that Roadmap has one item on it, that is fine too.
I think I would prefer “I am not sure on that yet, but we are working on defining at date,” to no response to a question on an AMA thread. Granted, that does not tell me anything, except that you care about your users’ questions. I am not trying to be a crass, and I don’t expect you guys to respond to everything. However, lately, my questions are being read, and ignored in general. Just take a note on that, as I am 100% sure I am not the only one.
I seriously do want the best for DGraph. I think the board (whoever the powers that be are— including yourself) need to come up with a plan going forward (even if it extremely slow). I don’t know that DGraph can go forward if your users are expected to wait until another loan comes around to get an update, plan, or roadmap.
Then let us know what that is. I think anything is acceptable to us, but no plan is not an acceptable option at all. It is the same premise from not getting a response.
I did a talk at CodeMash in Jan 2020 on DGraph. Then I thought it was a unique approach to horizontally scaling graph databases and I still do now. On a client project we’re actively building out a Dgraph implementation. It’s going pretty well. I hope to hear some optimistic news here soon.
–edit–
To follow-up on this, we are pretty concerned about the viability of future updates of dgraph, and moreover, concerned if a company will exist in a year or even 6 months. From reading above, it looks like the company underwent a significant staff reduction from 50 to 15 and are now internally struggling with identity and goals moving forward, while trying to balance the work 50 people were performing. This chain in it entirety reads opposite many positive articles we read leading up to choosing dgraph. We are left at odds now - keep using a product that has an open post discussing turmoil or head to another product. I understand this is an AMA thread, so I ask if you could clarify enough of the company direction/intent for a team to continue using the product.
In addition to what @rahst12 said, my team is in the same boat. We’re just starting out with a mobile app and quickly came to the conclusion that firebase does not fullfil our needs. We needed a combination of three things:
Very fast graph traversal queries to build social network feeds, recommendations, etc.
Full-text search capabilities
Fast time-to-market and extremely low costs
We settled for dgraph a couple of months ago because we deemed the $40/mo acceptable. We were slightly disappointed that dgraph does not support TinkerPop/Gremlin protocols, but given the flexibility of DQL we still convinced ourselves it was the right move. Unfortunately, we did get tangled up in the mess between GraphQL and DQL. We also got tired of waiting for stable field-level auth and therefore built our own authentication middleware using cloud functions. We were also slightly disappointed with the low response time on the forums and the frozen pull requests. But we still stuck through. Why? Because we (like many dgraph users), believe that dgraph is solving a real problem. And we were fine battling through any teething problems in the beginning as long as dgraph can thrive in the long term.
In other words: we are early adopters. Seeing through the problems and being as supportive as we can.
I’m sorry to say that this thread is the nail in the coffin for us. If we can’t trust that dgraph will be around 5 years from now, we simply don’t feel like the extra platform-dependent effort is worth it. And because every dollar counts for us (we are bootstrapping the project), I cancelled my subscription yesterday until we have more clarity. Some of the engineers are already looking into alternatives.
We do sympathize with your struggles. Getting funding can be extremely challenging. We therefore hope you will still be able to figure something out. One of the reasons we were so hopeful for dgraph was your marketing talents. It’s so much better compared to e.g. OrientDB (who are going through some internal problems as well). So please use those talents. Spend more time on marketing and keeping the community happy. The Zion update will keep us happy for a while. Now go make sure dgraph survives!
As to my AMA question: can you give more clarity on the future and survival of dgraph? What are your next steps? What are your plans to get more funding?
I am so sorry to see this post, and I thought I should share something as the noob and donkey kong in the room –which I totally relate to in @Juri’s post. When I first started using Dgraph, I definitely felt that there was a barrier to entry. Setting up Dgraph, there were many options to do the same things, and the information on Dgraph is extensive, but difficult to sift through. I would actually not mind being ELI5’ed to, given really pared down information, and a guide on common troubleshooting for setup etc. I also agree that the beginner portions can be further segregated to prevent the information overload. If you are working on documentation, I am pretty sure that you will never over-estimate the attention span or resilience of a noob like me That said, one of the best things that have kept me going (other than the fact that Dgraph is cool) is when my questions are always quickly and completely resolved on Dgraph discuss, which I really appreciate. For all the support I’ve received, I really hope you are able to turn the current situation around
we can keep the docs as they are - but create second docs for beginners with many ELI5 explanations and so on
And I think that even senior devs feel muuuuch more comfortable starting with a noob documentation, than with that pro docs where you don’t understand anything and have to spend big time to be able to comprehend everything. even senior devs who are building startups are using firebase/supabase to buildship quickly, because AWS UX sucks and GCP is so-so
new tech lives by noobs like us - we have much more time to spent in our lives because we are young - we spread word about dgraph via reddit and so on - as I linked the cloudflare CEOs stackoverflow response in my original post - the best marketing is a great UX so that even an HTML “programmer” who just started yesterday to code, is comfortable with the docs and is able to grasp what’s going on. these people are the top engineers tomorrow, and they are the ones who convince their company to use dgraph!!! this is the whole point of cloudflare marketing, most of their enterprise customers became customers because their developers said “Yo lets use cloudflare I am comfortable with that, i dont wanna use anything else” Top engineers today don’t want to try out new things, they stick with old things, because everyday 999999 new tech is release. tech is like fast fashion, many come and many go. only the ones with the best UX survive. Lookt at supabase, their product ain’t special; and even though they get one funding after another and everyday new customers.
Who needs more-expensive managed postgreSQL if you could use GCP managed SQL with postgreSQL and save money?? People who dont wanna waste time or/and are lazy, and want to ship build quickly without setting much stuff up!! dgraph currently feels like AWS: amazing tech but poor docs. We need a mix of AWS and supabase/firebase. Awesome tech like AWS, but awesome beginner friendly UX like firebase/supabase!! this is the way
what we really need are
second docs for noobs
short quick nice YT tutorials
new website
this awesome straightforward easy to understand explanations is what we need, this is what has to be on the website:
Yes. I am very concerned after hearing about this for the first time.
All of the information outside of this thread has been very positive dgraph developments.
We are also nearing release for our dgraph based service, which we are planning on running for many years. We were also hoping to get an enterprise contract post release.
I really hope there is some good news because I love dgraph, and I really don’t want to have to divest our implementation of it.
I’ve been around dgraph since 4 years, learning its functioning, reporting bug, asking for features, and I’ve always loved your technology, even if it’s sometimes difficult to known how to do specific things (the doc is ok but could be better, as many say).
I only use DQL, no cloud, no graphql, and my main recurring concern is bugs. Dgraph iterations improved on that, up to v21.03 which works great for my usage (game on connected words).
I tried 21.12, but I have many weird bugs (I recently did 2 unanswered posts here) that were not here on previous version.
So I only ask for a more stable release.
I really hope you and your team will find solutions to your problems.
I don’t know how to help except by reporting bugs.
I’m with you.
Well I’m a bit late to this party but I want to throw in my 2 cents. @mrjn thank you for focusing on building something truly amazing. The technical merits of how you have built Dgraph are truly impressive.
I am a frontend engineer, I am looking for a database that scales well, is efficient (affordable, serverless and pay by the drink ideally), provides clear and powerful solutions to all the standard db and search operations most apps need. This is why I have advocated for more powerful search capabilities and elasticsearch like query string query API.
Finally I think that the focus on GraphQL is a huge distraction, not that I think you should drop it but the specific flavor of technology is not what I care about at all, it’s a means to an end, be it sql, nosql, graph, columnar, rest, graphql, embedded, clustered, etc. I don’t really care and focusing on that level of detail kind of turns me off because what I really care about is how capable is this tool for solving my problem (build a powerful and efficient app)?
Write a simple schema and get a powerful API is the value proposition! Full stop.
GraphDB, GraphQL honestly are implementation details. If I could solve my problem easily while you went rogue and (gasp) broke from the graphql spec I would say do it every day. If I could get what I needed from a rest or other non-graphql api then I’m all for it. Actually if it were called something without Graph in the name, and you never really talked about graphs you’d probably be better off and then you could just focus on delivering on the actual value propoposition.
Unfortunately, not yet. The wheels are still in motion. Hope we can reach a conclusion by end-Jan. But, as I said, whatever the decision reached by investors, I’d support and help maintain a fully open source version of Dgraph.
Whenever you get some free time, could you do a introduction into the Dgraph codebase for a beginner wanting to contribute to Dgraph and what are the key things he should know or do. If you need a real use case, I can provide something for you.
If navigated properly, going fully open source might be actually the thing that will help dgraph adoption. Open core scheme sucks, but I guess there’s not much other ways how to lure in VC resources for highly technological project such as this.
Anyway as Anthony mentioned - intro to the code base would be great.
So let me chime in with my 2c. I’m a dev who has been working on systems in one form or another since before the 2000s and dev since 2003ish.
Developers nearly always don’t know what they want. Steve Jobs was 100% right on that. You have to tell them what they want and sometimes that’s in the form of a bludgeon.
My first question is who is doing the marketing? Before I threw my hands up in the air being exasperated at Prisma for releasing 7 straight updates for a trash database like MongoDB and ignoring issues that have existed for a year or so. I’d never heard of Dgraph until I started looking at GraphQL for a solution. I initially came across Hasura, but I gave up on them after I rage quit because I couldn’t get relay working with nextjs.
[Side note: Put me in the camp that looked at GraphQL as a fad and I didn’t know why devs were using it. Now that I have finally grok’d Dgraph. I drank the kool-aid. I think it’s a fantastic product and I hope it succeeds!]
I’m going to be rude here but I’m guessing nobody because your own YT channel is a bit of a disorganised mess. It’s fine for a senior dev to jump into, but as junior dev it would be daunting! Probably a lot of devs just took a quick look and went elsewhere.
Here’s a rundown of what I were to do, if I was the CEO.
You need a new website. Stat. You need to be clear why Dgraph exists and what it excels at.
Why it’s better than neo4j, supabase, hasura, prisma, graphql layer on-top of postgres.
These need to be broken down, so that the ELI5 crowd like me get it instantly.
Why you don’t have a competitor. How all other solutions are inferior.
How it’s webscale out of the box. How a similar postgres/mysql would cost.
In terms of mysql, there is singlestore
In terms of postgres, there is citusDB
Both of these cost a massive bomb in production. I know because I have used both in prod in mission critical apps.
How it’s easier to use than something like Prisma or Nexus+Prisma.
Prisma is plateauing and a lot of people are not happy with how they spend their time, they are waiting for critical features which may not come.
I’d make GraphQL front and centre and then make DQL advanced concepts.
DQL like golang and backend
I’d even go so far to have different websites:-
I’m new ELI5
I’m very technical, hit me baby!
I’m going to approach my boss, to migrate postgres to dgraph.
You need to get someone on the team asap (NOT A DEVELOPER) and have them eat what the new docs serve. Someone who is clearly well spoken, articulate and can explain stuff. Have them “Dog fooding” the product. You’ll know whether the docs work or not. Get developers who have never used the product and see if they can complete the tutorials and get feedback on how to make them better.
Actually make complex tutorials. Just doing a mutation and saying volia is not cool. Like how the existing golang and javascript libs work. If I have to start looking at the tests or codebase, the docs have clearly failed. You need to go into the weeds, as developers who are going to take this seriously; they are going to want to know how to do X, Y, Z, etc.
I’d also make documentation like:-
coming from mysql
coming from postgres
coming from mongodb
coming from fireship
and port over and existing project (in each of these) and transferring it into dgraph and hitting all the relevant points.
Also I’d have a “getting up to speed” document for the next point.
With better docs you need that social marketer to reach out to pretty much everyone. On Twitter and YT. Do a blitz with channels. Check this guy out: https://www.youtube.com/user/ssangha32
He and similar developers like him, they build out clones and other toy apps for ordinary people to get into development. What does he use? Firebase and firebase sucks!
But he uses it because getting up and running is very quick and simple to do. It’s also FREE for him. Very low hanging fruit.
If I were the CEO, I wouldn’t be sitting on my hands thinking what to do. I’d be getting the social marketer to be lining up calls, zoom meetings and emails with those on YouTube and asking them to follow the “getting up to speed” document, so they can learn quickly and have Dgraph as their goto graphql database.
Also, I’d have a cheap as chips/free tier for Dgraph. Specifically for these YT developers. Just enough to make a project and enough for a new developer working through the YT video to replicate it.
See this sort of thing has a knock on effect. If developers start putting Dgraph on their resume, employers will ask them about it. Now you have word of mouth advertising!
Who is using Dgraph? I don’t care about Fortune 500 companies. Listen, you want to win the war right? You ain’t doing that with these types of companies. You do it in the trenches. Getting dirty. Marketing is a knife fight. You need YT content creators to consistently be mentioning Dgraph and why it’s so awesome. You should start putting that page into 2 tiers. Fortune 500 and “startups”. If you have an approachable air, devs will flock to you and start recommending you.
If you don’t start to change mindsets from, I need to use Postgres and some graphQL layer. To: I need to use GraphQL as the centre of my infra. You aren’t going to win this war. This is the mindset you need to have.
Remember, developers don’t know what they want. You need to tell them! Customers need to see something about 7 times before it registers!
Finally, with that social marketer. You need to go on podcasts, dev shows, hit up vercel to be the goto solution for graphQL. Be literally everywhere and have people talking about you. And do this constantly, not one and done.
I’ve seen a few projects sprout up and then wither away and it’s very sad to see. Now that I have found Dgraph, I wish it to succeed.
As a side point. I’d even ask the community for help.
Redesign the website
Setup a war room of individuals
who can do the social reach out for you
who can make videos hitting a particular pain point
who can make clear concise tutorials
Lastly:
I know it sucks when this is an issue. I’ve been there too. Sometimes going back to basics is the best kind of solution. Remember, taking action is how you’ll solve nearly all kinds of issues.
I’ll finish with:
Much like how rethinkdb joined the linux foundation?
I know you meant Firestore here, but the Fireship guy was going to do a video to help marketing where he builds something (the channel now has over a million subscribers)… and guess what happened…? This is DGraph’s fault, I tried to help with this as at the time I was directly communicating with the Fireship guy, and no one even responded to my email! One of the many reasons I get so worked up about DGraph! They never followed through, and ignored people trying to help!
I also think setting up GraphQL with Apollo / URQL is not easy, and then you have to understand the tokens for security. All of these things need better documentation, while other competitors are clear.
DGraph does terrible marketing, and I think it always has.
You straight up cannot build a test app with the free tier. It is 100% impossible with the very limited requests. It is Pointless! This is one of those things we have been telling DGraph for a long time now, and it gets ignored.
Great posts. Agree on everything here. Marketing, Documentation, and as we used to say when the Discord server first started…
DGraph needs to eat its own dog food by actually using its own documentation, test tiers, and product so that it can see where it falters…
Another one of the problems with Theory vs Practice…
EDIT:
It looks like they purchased the rights for the code first. If the VCs don’t go forward, they have to release the code. The investors may not want to do that. Then again, I don’t know how all the licensing work.
I’ve actually been witness to this particular problem. It’s culture. That’s the problem. Someone else needs to be put in charge of marketing and have free rein. You know how with some companies, the CEO is replaced and then the company bounces back. Well it could be the same here. Sometimes technical founders don’t make the best marketers, just saying…
That is very unfortunate.
Update. Here’s how you do outreach to YTers.
I’m on Jack Herrington’s discord. He’s done a lot of good works on his channel. Very thorough. So I thought, why not reach out?
Sometimes that’s really all it takes. If he finds it interesting, he’ll do a video. As someone outside of the tent so to speak. This is all one can do to promote Dgraph.
Back story – we had to do major layoffs in June after we failed to raise a bridge round. We then tried to raise an outside round in Aug / Sep, but failed there as well. We’re investigating options about how to keep the project running.
what does this mean for existing customers who are depending on paid instances? what’s the worst-case scenario timeline for support ending?
That said, one of the best things that have kept me going (other than the fact that Dgraph is cool) is when my questions are always quickly and completely resolved on Dgraph discuss, which I really appreciate. For all the support I’ve received, I really hope you are able to turn the current situation around 
