built for web-scale production environments written entirely in Go. Fast Sharded and Distributed (Distributed Joins, Filters and Sorts) Horizontally scalable Consistent Replication via Raft Highly Available by design Fault tolerant
Dgraph is 3x-6x faster on a read-write workload. At least as fast on read-only. Link to full benchmark code (https://github.com/dgraph-io/benchmarks/tree/master/data/neo4j)
written in Go. Loading 21M RDFs Dgraph is 9.7x faster Queries Dgraph is 5x - 36.6x faster Link to full benchmark code (https://github.com/ankurayadav/graphdb-benchmarks)
like C, Graph query language is like Go or Python. Just like high level languages allow you to express logic faster, Databases allowing more complex queries allow you to iterate on your application faster. They achieve this by cutting down your application code by at least half.
forces you to do: Because SQL does lesser things, you need to do more things. Maintain a strict schema. Data duplication to avoid slow joins. Pre-compute counts for foreign tables to allow e cient sorting.
does: Flexible sparse schema, with real time modi able data types. Join is a single lookup away, so no data duplication. Simplify schema. Any counts can be done cheaply in real time.
-> Post) | (New edge from Post -> Vote/Comment) Timestamp | Timestamp Author | Author VoteType (for Vote) | Score (for both Vote and Comment) Text (for Comment) | Text (for Comment)
use case, which is to provide ACID transactions. Great solution to store nancial data. For everything else, I think a well designed graph database is more ideally suited. Cuts down on the amount of coding e ort required, using the power of graphs to run complex queries.