We decided to make all of our code available on GitHub regardless of the license (unlike OrientDB if I understand correctly) so anyone can see what the Enterprise Edition really does.
Let us know if this is confusing. If you don't want the proprietary code, you can always only use the open-source version of Dgraph with `make oss`.
I'm also really interested in seeing where GQL (gql.today) is going, adopting a community-wide standard would be a definite yes from us.
In any case, thanks for your feedback. I'd love to hear more on how we can make our product better, feel free to email me at [email protected].
Yes, we fixed all those issues and we're currently rerunning all of the jepsen tests on our new release coming up in a couple of weeks.
Working with Kyle is always a pleasure, so we definitely don't discard having him have another look at our database in a bit - once there have been enough changes to it that our trust on the project is not where it should.
I think Dgraph is not a great choice for this right now, as it seems you're looking to be able to use those different replicas offline too?
We use RAFT to reach consensus on transactions, so the nodes need to be able to communicate with each other.
I'm definitely adding this as a feature request though, I would love to chat with you more about your requirements if you're interested ([email protected]).
We are not hyping, we're blogging about our fundraising success while working on our new release which will include a series of benchmarks which we'll be happy to share with all the details, obviously including source code and hardware setup.
Until then, feel free to get in touch with us if you have any specific questions or need help with performance analysis!
GraphQL+- will still be a thing, since GraphQL doesn't provide all of the things we need to manage a database.
That said, we're working on a pure GraphQL support, which will help with any kind of integration with other GraphQL projects. This is really exciting and will hopefully help many that do not want to spend their time learning Cypher or Gremlin and already know GraphQL.
Another project we're working on is offering Dgraph as a service. We're currently doing this with some of our customers and so we have the expertise and trust on our product necessary to run this service at scale. The ETA for this is not as clear but I do expect to have a private alpha by the end of the year.
Thanks! We're very happy to finally share the announcements.
We bet on GraphQL very early on, right after the initial specs came out, as their language was surprisingly similar to what we were working on. We have not looked back since then, as GraphQL growth is pretty impressive as the creation of GraphQL foundation.
We are considering supporting cypher because many people are actually quite used to it, it's an open specification, and would also help us make more "apples to apples" comparisons with other databases (hi, Neo4j!).
For now, though, we're focusing on providing native support for pure GraphQL (not only GraphQL+-) but we don't discard adding Cypher later on.
As for the pricing, this is for a cluster with 2 nodes (1 alphas + 1 zero) and includes support and access to enterprise features. This, actually, ends up being often more affordable than our competition (or so our customers have told us).
We believe it's time for Graph DBs to become the default storage system, in the same way people consider SQL and no-SQL options nowadays, so our target audience is much wider than just people interested on graph databases.
Lastly, regarding Mongo + Redis I was not aware of this so I'll be checking it out soon and then I can give you my opinion :)
Happy to continue the conversation on slack.dgraph.io or discuss.dgraph.io!
Most graph databases are being used as secondary systems, often used as indexing for other databases, etc.
We believe this is due to a lack of features or performance at scale.
Our goal at Dgraph is to be used as main storage similarly to how people use Postgres or Mongo.
Happy to ask Manish (the author of the post and CEO of Dgraph) for more details!
We (I work at Dgraph) have data redundancy when you have multiple replicas for a given group - but that's an optional feature.
Thanks!