3 ms·
I've been using DGraph for quite a while now in a side project of mine. I looked at a number of other graph dbs, and landed on dgraph for a few reasons. a) I
by staticassertion 8y ago
I've been using DGraph for quite a while now in a side project of mine.
I looked at a number of other graph dbs, and landed on dgraph for a few reasons.
a) I like the query language. It felt natural to me. That's just my opinion though. Other languages felt cumbersome, and I didn't feel like I was operating on a graph.
b) I needed write performance. I'd talked to colleagues about their experiences (I have some friends at graphy companies) and every time I asked "what about X graphdb? could it handle this write load?" the answer was "no, definitely not".
I chose dgraph and it's been working like champ. Support via slack has been solid, they're focusing on the right things (performance, correctness), and I have a lot of confidence in the future of the project.
- mrjn 8y agoNot just you, a lot of Dgraph users appreciate the intuitive model of GraphQL+- (modification on GraphQL), and how it fits naturally with JSON and apps. When I started in 2015, I didn't imagine that our decision to use GraphQL would become such a major "feature." GraphQL has taken off like a wildfire, which was hard to imagine back in 2015 when it just launched in July 2015. In fact this year, we plan to align GraphQL+- even more with the official GraphQL spec. Stay tuned! re: write perf, it just got a whole lot better with 3 changes I made recently, and there're still a lot of room for optimization: https://github.com/dgraph-io/dgraph/commit/b7189935e6ec93aec04762321252b70f98466985 https://github.com/dgraph-io/dgraph/commit/b7189935e6ec93aec...
- staticassertion 8y agoLike I said, a big part of feeling confident in my choice to use DGraph is the direction - the improvements to the QL and performance, as well as the Jepsen tests, are exactly the work I want to see as a consumer. And that is one hell of an improvement. Nice work.