
Dgraph is a next generation graph database with GraphQL as the query language - velmu
http://react-etc.net/entry/dgraph-is-a-next-generation-graph-database-with-graphql-as-the-query-language
======
mosselman
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.

~~~
woodcut
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.

~~~
mosselman
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?

~~~
woodcut
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. :)

~~~
bogomipz
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-...](http://google-opensource.blogspot.com/2014/06/cayley-graphs-in-
go.html)

~~~
woodcut
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.

------
aymanc
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.

------
dang
[https://news.ycombinator.com/item?id=11322444](https://news.ycombinator.com/item?id=11322444)

------
diegoperini
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?

