[HN Gopher] Retrospection and Learnings from Dgraph Labs
___________________________________________________________________
Retrospection and Learnings from Dgraph Labs
Author : mrjn
Score : 80 points
Date : 2022-09-16 15:39 UTC (7 hours ago)
(HTM) web link (manishrjain.com)
(TXT) w3m dump (manishrjain.com)
| kk58 wrote:
| 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
| throwabro1301 wrote:
| > The problem was that it's hard to convince a DevOps person to
| add a relatively unpopular database to the tech stack. However,
| the same person won't bat an eyelid (slight exaggeration), adding
| a new cloud service to the stack.
|
| Actually I hate the guts of cloud services. I hate adding another
| API key, account to my 1password, credit card, etc. I just want a
| Helm chart and be done with it. If anything, Kubernetes & GitOps
| is a way more ergonomic way for the vendor to get into your stack
| than stupid accounts are.
| tommiegannert wrote:
| Thanks for the perspective.
|
| Sustainable, open, software development feels like a problem
| that's still not solved. How do cloud offerings, consulting,
| extra features ("open core") and donations compare in terms of
| keeping development move forward? Have there been studies around
| that?
| mardifoufs wrote:
| >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!
| justtoni wrote:
| Maybe they hired a CFO who said on his first day: "I am sorry,
| but you are fucked".
| threeseed wrote:
| Manish allowed a new CEO, Gary Hagmueller, to take over on
| advice from his investors at Redpoint.
|
| The two didn't get along and Manish was largely sidelined.
|
| And then depending on who you talk to the company failed
| because of Gary (poor fundraising, strategy etc) or Manish
| (poor product, management).
|
| The investors Dgraph had e.g. Redpoint, Airtree, Grok have an
| excellent reputation so there is definitely more going on then
| has been let on.
| zinclozenge wrote:
| The cloud service is probably the biggest one. But it's not just
| that. JAMstack is getting more and more popular, so you'll need
| to support "serverless" as well as a way to query via HTTP. Which
| means you'll need some kind of "Data Gateway" proxy on top of
| robust authentication and authorization. There are more and more
| "scenes a faire" to be competitive in the DBaaS market and I
| don't think dbaas startup founders are aware of it.
| chrisweekly wrote:
| > "scenes a faire"
|
| I was unfamiliar w this French phrase; here's a definition:
|
| obligatory scene : a plot element that is standard for a
| particular genre
| the_duke wrote:
| I tried Dgraph a year or two before it went bust.
|
| I can confirm the query language mistake. The Graphql-alike was
| different enough to be unfamiliar, and still felt somewhat
| awkward to use. The other query languagewas pretty badly
| documented and also wasn't great. Cypher isn't perfect, but it's
| pretty decent.
|
| I also ran into a trivial bug around a comparison in a query not
| returning correct results and pretty much immediately gave up.
| (It don't remember the specifics, it might as well have been API
| misuse).
|
| But the biggest issue with all these graph databases for
| traditional application development is schema. Most of them are
| schemaless or have some half-assed, basic schema support. Nebula
| is the only one I can think of with proper schemas.
|
| This is not what you want for your primary data store! Even more
| so if logic is driven by JavaScript, or even Typescript since
| there are still plenty opportunities to mess up.
|
| I wish there was a proper multi-modal DB that combines the best
| of both the relationalnand the property -graph models. The
| recently announced SurrealDb might fit the bill.
|
| Graph stores are plenty popular for secondary workloads with
| special requirements, which is not dissimilar to Elastic search
| for the search domain.
|
| I don't see that changing anytime soon.
| andrewcl wrote:
| Is Dgraph out of business? I still see their product website
| up?
| threeseed wrote:
| They have a new CEO, Akon Dey:
| https://www.linkedin.com/in/akon-dey-34a757/
|
| So still in business although he seems lacking in senior
| management experience.
| thrway3344444 wrote:
| They seem to have hired a number of people over the last few
| months. Could be a recapitalization + new leadership.
| 1st1 wrote:
| Check out EdgeDB.
| lmeyerov wrote:
| Good 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.
| jandrewrogers wrote:
| An important aspect of graph database TAM is that the current
| market size is somewhat defined by the poor scalability and
| performance of existing graph databases. Many interesting
| applications simply don't fit within the limitations of current
| graph database platforms, and those limitations haven't changed
| much in the last decade.
|
| I would agree that the "database" part is not that important.
| It is the notion of scalable graph analysis that sells a
| platform. However, for sufficiently large graphs (most of the
| interesting apps are in this class), GPUs often don't help much
| versus CPUs in my experience.
| stack_framer wrote:
| I 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.
| jhoechtl wrote:
| GraphQL is lacking lots of expressivenes. Does it even have
| group by having? DQL is more powerful.
| bawolff wrote:
| GraphQL kind of has the reputation of not supporting super deep
| expressive queries. It is meant as a frontend query language
| after all.
|
| If i saw a graph db with that as its primary language i would
| probably assume that its targeting a very different segment of
| the market than most graph dbs, and doesnt support deep recursive
| queries, and probably move on without a second look. I wonder if
| this sort of attitude hurt dgraph.
| taubek wrote:
| Really nice read, and great insight into the startup world.
| harikb wrote:
| > We took the product from 0 to 1M ARR, proving a strong signal
| of the product-market fit.
|
| There may have been a slow-&-steady path to get to a mature
| state. But given the expectations of tech & vc scene these days,
| I can't blame the path you took. Good luck with the next venture.
|
| I am glad that DBs like Postgres/MySQL, Sqllite etc got their
| freedom to evolve and slowly mature before the madness of fast-
| growing companies caught up to them.
| onebot wrote:
| I 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 management style. 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. That seems wrong to
| me. Either he is a the best programmer in the world or didn't
| hire well. Not really sure tbh. But I wanted to love the product
| but it had too many poorly working features and could have de-
| scoped a bit and made them good.
|
| FWIW I am really excited by surrealdb. I think it is the sweet
| spot that dGraph should have been.
| staticassertion wrote:
| 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.
| dpkirchner wrote:
| > 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."
| [deleted]
___________________________________________________________________
(page generated 2022-09-16 23:00 UTC)