Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Retrospection and Learnings from Dgraph Labs

manishrjain.com

Post reply on HN
Print view View original

21–30 of 40 posts

Re: Retrospection and Learnings from Dgraph Labs

#21

Post by threeseed »

mardifoufs wrote: post #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!

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.

Re: Retrospection and Learnings from Dgraph Labs

#22

Post by threeseed »

andrewcl wrote: post #7
the_duke wrote: post #5

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 imm…

Is Dgraph out of business? I still see their product website up?

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.

Re: Retrospection and Learnings from Dgraph Labs

#23

Post by 1st1 »

the_duke wrote: post #5

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 imm…

Check out EdgeDB.

Re: Retrospection and Learnings from Dgraph Labs

#24

Post by bawolff »

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.

Re: Retrospection and Learnings from Dgraph Labs

#25

Post by jandrewrogers »

lmeyerov wrote: post #14

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 use…

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.

Re: Retrospection and Learnings from Dgraph Labs

#26

Post by lmeyerov »

jandrewrogers wrote: post #25
lmeyerov wrote: post #14

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 use…

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 scala…

agreed, and we've heard heart-attack-level pricing pushback for the few db's that do scale well

likewise, for analytics, we're seeing a bit of a split:

- DB side: Traditional real-time graph analytics (pattern search, ...) can often be done on extracts from KV-store level queries, so just use those and post-process the compute ("extract 1-2 hop neighborhood, then cross-product in lang xyz"). Like the old Titan -> Cassandra days. GPU can be nice for accelerating a simple inferencer here (e.g., a T4), but not necessarily the actual fetch. Gets a bit more blended in 'real' knowledge graphs, but that's more R&D. (Edit: I believe Facebook's at-scale graph engine successfully runs on top of SQL for related reasons.)

- AI side: Massive interest in GNNs (we're active here!) as starting to eat the lunch of the result quality that traditional graph analytics can give. Basically the pendulum swinging back to graph for areas like recommendors & classifiers. Shopping carts, fraud, cyber, etc. These had gone the way of ML + AI systems for awhile now, but with GNNs becoming practical, best of both. And... GPUs matter over CPUs again.

Funny enough, we're getting into a bunch of vector search scenarios, and because of our particular scale & query richness needs... looking at OSS graph DBs and pairing with GPU nodes. /insert "why not both" meme here

Re: Retrospection and Learnings from Dgraph Labs

#27

Post by throwawayays »

threeseed wrote: post #21
mardifoufs wrote: post #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!

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…

Tangential… Airtree historically has a pretty poor reputation amongst founders who have taken money off them and amongst angel investors. I don’t have first hand knowledge but at least half a dozen unique second or third hand data points => dodgy tactics even at early stage and can micromanage founders.

Re: Retrospection and Learnings from Dgraph Labs

#28

Post by HyperSane »

lmeyerov wrote: post #26
jandrewrogers wrote: post #25

Earlier quoted context omitted.

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 scala…

agreed, and we've heard heart-attack-level pricing pushback for the few db's that do scale well likewise, for analytics, we're seeing a bit of a split: - DB side: Traditional real-time graph analytics (pattern search, ...) can often be done on extracts from KV-store level queries, so just use those and post-process the compute ("extract 1-2 hop neighborhood, then cross-product in lang xyz"). Like the old Titan -> Cas…

"the few db's that do scale well"

Which ones?

Re: Retrospection and Learnings from Dgraph Labs

#29

Post by HyperSane »

stack_framer wrote: post #12

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 G…

They should have used Cypher.

Re: Retrospection and Learnings from Dgraph Labs

#30

Post by random3 »

HyperSane wrote: post #28
lmeyerov wrote: post #26

Earlier quoted context omitted.

agreed, and we've heard heart-attack-level pricing pushback for the few db's that do scale well likewise, for analytics, we're seeing a bit of a split: - DB side: Traditional real-time graph analytics (pattern search, ...) can often be done on extracts from KV-store level queries, so just use those and post-process the compute ("extract 1-2 hop neighborhood, then cross-product in lang xyz"). Like the old Titan -> Cas…

"the few db's that do scale well" Which ones?

+1 - curious
Post reply on HN