Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I find Dgraph to be one of the most interesting of the current batch of non-relational data stores.

I've wanted a robust, easy-to-use graph database for years (ever since reading about the crazy brilliant graph database stuff that goes on inside Facebook https://www.facebook.com/notes/facebook-engineering/tao-the-... ) and Neo4J never really cut it for me.

Watching Dgraph mature - and survive two rounds of Jepsen with relatively decent marks - is intriguing. I don't have a project that needs it yet but maybe something will come up soon.



Neo4j is... conditionally alright. The main problem is that their marketing has a bad case of MongoDB syndrome.

N4J: "We sell cars. Our cars can be anything you want, and are at least pretty good at everything, and often great and even better than any other possible car you can get!"

Client: "Cool, I need a spacious four-door sedan with good gas mileage that's also a race car"

N4J: "Oh yeah, definitely, no problem, this is the product for you, totally fits your use case!"

Client orders car, it arrives, is in fact a delivery van that likes to stall at traffic lights

Client: "Uh. This would be useful if I needed a delivery van for a route with no stops, I suppose."


> Neo4J never really cut it for me.

What did you find lacking in Neo4j?


In my experience, from ~1.5 years ago, performance became an extreme challenge to overcome if you wanted to service user facing requests in <100ms (for a non-trivial sized graph). I really did enjoy Cypher though and the tooling around it was very polished. Tempted to try it again now that they have a new version.


Last time I looked at it it seemed to really want me to use Java.

Turns out the official Python client library is five years old now so I clearly need to update my mental model of what it can do!




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: