Dgraph is a next generation graph database with GraphQL as the query language | Hacker News Reader

Dgraph is a next generation graph database with GraphQL as the query language

react-etc.net

64 pointsvelmu9 comments

Could someone in the community with experience in graph databases and dgraph in particular shine some light on the quality of dgraph? There appears to be a lot of exposure, but the lack in streamlined installation or examples of production environments (as far as I could see) makes it hard to judge whether it is a good option for integration with new projects. Also "...our Samurai equity multiplier." put me off a bit.

It's an RDF graph mapped to a key-value database, so you describe edges in a tuple {subject-predicate-object} such as "tom-likes-frank" and while the complexity you can model depends on how you define your schema, RDF is good enough for most applications. However it isn't easy to define weighted graphs -afaik- without creating numerous predicates for discrete intervals.

I'm pretty positive about this project, it's like google cayley if it hadn't have got bogged down in trying to support numerous database drivers. It'll show its strength if and when it implements raft and reaches a stable production state.

Thank you for the clarification.

How would Dgraph compare to Neo4j for example?

I have looked at google cayley's as well (looked through the docs) and I must say I liked the premise. Do you think the support of multiple databases has degraded the database's performance?

I worked on implementing a backend for google cayley, the issue is the iterators abstract how a backend actually works so it becomes harder to optimise without introducing tighter coupling, also imho effort is better spent on more important things like high availability etc. I haven't touched it in a while so i can't speak re. its performance today.

I've never worked with Neo4j but it's a stable and matured product with numerous large scale deployments, enough said. :)

Could you elaborate? I was under the impression that Cayley supported MongoDB and LevelDB as backends:

http://google-opensource.blogspot.com/2014/06/cayley-graphs-...

yeah cayley supports numerous backends that do have replication such as mongodb and postgres or cockroach db. The issue being that a complex query consists of multiple stages like 'friends of friends of friends'. So if you're using a remote backend iterating over the result of a query then recursively making new queries results in performance that is at best poor.

i'm not sure if it's only me, But whenever i needed graph-db type queries i found much more success with targeted relational database queries. they take a lot longer to implement but perform feasible results (sometimes u might need to buffer a few things, some pre-calculations here and there). (neo4j vs mysql innodb on multiple layered recommender systems)

The thing is that i don't see the point of such a graph db if not for what i just mentioned.

any clarification would be great.

https://news.ycombinator.com/item?id=11322444

Is there any graph based dbms solutions that uses its own storage backend, engineered for graph operations exclusively in a way that key value stores or relational cannot compete? If so, are they reliable?

Reply on news.ycombinator.com