Retrospection and Learnings from Dgraph Labs
manishrjain.com
Retrospection and Learnings from Dgraph Labs
1–10 of 40 posts
Re: Retrospection and Learnings from Dgraph Labs
#2The 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 "scènes à faire" to be competitive in the DBaaS market and I don't think dbaas startup founders are aware of it.
Re: Retrospection and Learnings from Dgraph Labs
#3> 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.
Re: Retrospection and Learnings from Dgraph Labs
#4Thanks 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?
Re: Retrospection and Learnings from Dgraph Labs
#5I 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.
Re: Retrospection and Learnings from Dgraph Labs
#6The 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 "scènes à faire" to be competitive in the DBaaS market and I don't think dbaas startup founders ar…
> "scènes à faire"
I was unfamiliar w this French phrase; here's a definition:
obligatory scene : a plot element that is standard for a particular genre
Re: Retrospection and Learnings from Dgraph Labs
#7I 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?
Re: Retrospection and Learnings from Dgraph Labs
#8I 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 seem to have hired a number of people over the last few months. Could be a recapitalization + new leadership.
Re: Retrospection and Learnings from Dgraph Labs
#9> 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.
Re: Retrospection and Learnings from Dgraph Labs
#10I 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.