[motohagiography]

I've done development on an app with Neo as the back end, and what I liked about it was mainly py2neo and the cypher query language. Even after developing in it, approaching another graph in DGraph was conceptually impenetrable, as my impression of dgraph was they had a bunch of unnecessary and poor abstractions in their documentation. The next candidate is the redis graph, but I haven't. With Neo, if you learn cypher, you literally don't need to know anything else about it to be useful in it, which brings me to what I think their real market is.

The opportunity I understood after using Neo was the big product play would be a kind of mental shift for enterprise data analyst users whose jobs exist in excel/powerbi today with power users using Cognos, and less devops/SaaS company/etc. I over-use Apple as an example, but if Apple entered into enterprise data products, Neo would be the kind of thing to be the underlying tech for it, as if you are an apple user, an apple'ey analytics tool would be based on users producing and reasoning about their data with graphs instead of tables, if you could imagine a kind of photoshop for data, or a fundamental conceptual change from spreadsheets to graphs. They aren't as competitive as a data tool, but I think they are unrivaled as a knowledge tool.

The tech is really great, but the product piece appears to have been a challenge because the use cases for graphs have been very enterprise'y, which has limited adoption because people who operate at that higher business logic level of abstraction that graphs enable are not the people picking and adopting new technologies. The growth will come from younger people who learned python in high school, and have a more data centric world view. Maybe that's the play.

Anyway, as a user I can see why they got participation on an F round. Imo, they've solved the what/how/why and have done some amazing science and engineering, and what I hope that money buys them is some magic.

[mrjn]

(author of Dgraph here)

> my impression of dgraph was they had a bunch of unnecessary and poor abstractions in their documentation

I'm surprised to hear that. Dgraph uses GraphQL (and DQL, a fork of GraphQL) as the query language -- which is a lot more widely adopted language than Cypher. Dgraph users really like the simplicity and intuitiveness of the language and ease of use of the DB.

I'm curious what was confusing in documentation.

[motohagiography]

Nice! It's been a few years but what I remember is that if I ever had a chance to ask, I was going to ask this: What was the problem that calling what laymen call attributes/properties Predicates solved, are they just attributes, and is there some other mathematical property of DGraph predicates that makes them different from normal attributes that a user should know?

Literally every dgraph user must necessarily know the answer to that already, or maybe they just mentally black box it and work around it, but at the time, my impression was non-users don't know this, and if I'm adopting a whole new taxonomy I need extra incentives to know it's worth while. It's probably an excellent and even superior technology, but what read as auteurism in the product at the time made me reconsider how much time I wanted to invest before encountering another one.

Anyway, coming from being a Cypher user, the learning curve for the use case of "I want to create nodes of different types with attributes, with relationships of types with attrbites, then CRUD them and verticies with a Flask app" felt a bit steep after that.

SQLite would do the trick, but I wanted consistency from my business logic to a grammar, to a data model. It's very easy to encounter graphs and just think we're not smart enough for them or our problem isn't graphy enough, but given the ease with which I could encode a grammer into cypher, I reluctantly gave up on dgraph. That said, I'm not a gremlin/tinkerpop fan either, as from a top-down user use case, it wasn't satisfying either.

DGraph has a lot of users and customers who love your product and the smartest people I knew recommended it to me, so my issues might not register, but there were a few experiences going through the tutorials that made me wary I was sinking costs into it relative to my use case, e.g. I have 1 week to build a PoC Flask app with a graph on the back end, and then scale it if the customer cares. That's what I used Neo for, and didn't use dgraph for, even though I figured I'd hire developers to rewrite it for dgraph if it got off the ground.

Anyway, long way round, but I'm a long time believer and user of graph techs and want everyone in that market to succeed.

[topicseed]

Amongst all graph databases I tried, Neo would land third and last. Dgraph and ArangoDB would definitely be ahead in terms of developer experience from data loading to regular transactional use.

But I do appreciate all the effort Neo4j put for years in educating us all on graph databases, use cases, and just drawing attention and awareness.