To be honest, the customer service and as super poor and the CEO was not interested in having conversations with a potential customer also they missed out the graph analytics train which was very surprising
Retrospection and Learnings from Dgraph Labs
11–20 of 40 posts
Re: Retrospection and Learnings from Dgraph Labs
#12I used Dgraph as the primary data store in a production app for over a year. I really enjoyed thinking of our model in terms of a graph, and finding creative ways to query what we needed.
The biggest pain point for me was the query language schizophrenia: Incomplete support for GraphQL, or their custom Dgraph Query Language (DQL). As Manish said, they missed the GraphQL train. They really should have gone all in on GraphQL, and only GraphQL.
Re: Retrospection and Learnings from Dgraph Labs
#13I may be in the minority opinion here, but I think the biggest issue was the product constantly changed and tried to be too many things. The product-market fit seemed to be on be "The GraphQL" db. But they really just did all this other complex stuff and by the time they were going in that direction ran out of steam. I don't know Manish personally, but there seems to be a lot of negative sentiment about his managemen…
> He has been quoted as say (to the effect) that his engineers were not as good as him and he would have to go in and "fix" stuff.
I wonder if this sentence has similar basis:
From the blog post: "Dgraph took a hit suddenly due to a critically wrong hire — which made us go from a “things are looking great” to “sorry, you’re out” within a week."
Re: Retrospection and Learnings from Dgraph Labs
#14Good reading, I've been curious!
Some observations as a team active here.
We're adjacent / complementary because we make graph db's (and regular SQL/databricks/etc.) more actionable via rich & scaled graph viz workflows (analyst-facing) + graph automl (automation-facing), so sometimes end up working alongside graph db co's at enterprise/gov/tech customers so not just a silo'd db. I think we only saw ~1 production user of dgraph though, so entirely based on their competitors:
* Graph DB TAM: Neo4j revenue is probably around $200M/yr now, and probably another $100-200M across the other graph db vendors. (Market analysts say the graph db market today is $1B+ but seems rosy.) Importantly, because of analyst + AI use case growth in areas like recommendations, anti-fraud, cyber, etc., and streamlining of infra via cloud/docker/etc, everyone good is growing quite well, and I expect good YoY growth for everyone for at least 3 more years. The AI market likely a much bigger leap for graph, tho less clear for these graph db and especially cpu ones.
* GraphQL TAM: Agreed. But may be a bigger culture shock for a pivot. Not ready for Series B levels of expections. leading to...
* Revenue: Super risky, lacking big & growing revenue, to assume a Series A, and then a Series B (!), unless you have a special trick like having ties to the chinese government or being a successful serial founder people just trust.
* ... Tip for people looking at jobs: ask revenue / spending ratio + how many years in the bank when not profitable. If a b2b team can't make revenue work after $xM raised, they're on the path for stressful grinding, dilutive bridges & shutdown. VC treadmill grows expectations, so coming in from behind is asking for PE to take over or an acquihire where only the founders win.
Re: Retrospection and Learnings from Dgraph Labs
#15>Dgraph took a hit suddenly due to a critically wrong hire — which made us go from a “things are looking great” to “sorry, you’re out” within a week.
I don't understand what this could mean? How can a single hire be so impactful and so quickly? I guess the team was small but even then I'd be very interested to know how that could happen!
Re: Retrospection and Learnings from Dgraph Labs
#16>Dgraph took a hit suddenly due to a critically wrong hire — which made us go from a “things are looking great” to “sorry, you’re out” within a week. I don't understand what this could mean? How can a single hire be so impactful and so quickly? I guess the team was small but even then I'd be very interested to know how that could happen!
Maybe they hired a CFO who said on his first day: "I am sorry, but you are fucked".
Re: Retrospection and Learnings from Dgraph Labs
#17Really nice read, and great insight into the startup world.
Re: Retrospection and Learnings from Dgraph Labs
#18I used Dgraph as the primary data store in a production app for over a year. I really enjoyed thinking of our model in terms of a graph, and finding creative ways to query what we needed. The biggest pain point for me was the query language schizophrenia: Incomplete support for GraphQL, or their custom Dgraph Query Language (DQL). As Manish said, they missed the GraphQL train. They really should have gone all in on G…
GraphQL is lacking lots of expressivenes. Does it even have group by having? DQL is more powerful.
Re: Retrospection and Learnings from Dgraph Labs
#19I may be in the minority opinion here, but I think the biggest issue was the product constantly changed and tried to be too many things. The product-market fit seemed to be on be "The GraphQL" db. But they really just did all this other complex stuff and by the time they were going in that direction ran out of steam. I don't know Manish personally, but there seems to be a lot of negative sentiment about his managemen…
I believe what he said was that he can move a lot faster on things than his engineers. As the founder of a company I'm sympathetic. No one could ever understand the product as well as me, at this point, because I built almost all of the critical code (this is less and less the case, thankfully, and I'm very happy to say that there are now solid chunks of code where I am NOT the authority on code). That's not "they're worse engineers", they definitely aren't lol. But if you've spent years of your time on a codebase it's going to take years for anyone to be as quick to fix a bug.
I think this is sort of obvious. Imagine fixing a bug in your own personal project, compare that to fixing a bug in someone else's project. You can probably see the error and guess what the bug is, accurately, if it's your project. With someone else's code you're going to have to reverse engineer the system first.
Re: Retrospection and Learnings from Dgraph Labs
#20[deleted]