campoy

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

Comment · 7 years ago

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.

Comment · 7 years ago

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]).

Also, have you considered CRDTs? (https://en.wikipedia.org/wiki/Conflict-free_replicated_data_...)

Comment · 7 years ago

We are happy to get new feature requests on github.com/dgraph-io/dgraph!

SPARQL is something we're considering but we haven't heard much interest from any of our customers so it's not very high up on our roadmap.

I'd love to chat with you to figure out how adding this could help your use case though. You can reach me at [email protected].

Cheers!

Comment · 7 years ago

Hi there,

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!

Comment · 7 years ago

Thanks for sharing these, cool handle name btw :)

Comment · 7 years ago

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.

I hope that helps, if you have any other questions feel free to join us on https://slack.dgraph.io or https://discuss.dgraph.io, or reach me directly on [email protected]

Comment · 7 years ago

I would love to chat with you about your needs and requirements in the healthcare field!

If you're willing to share some info, my email is [email protected]!

Comment · 7 years ago

Let's chat! We're working on improving our docs specifically regarding the data modeling aspects.

If your use case is open source we could even use it as one of our case studies :)

[email protected]

Comment · 7 years ago

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!

Comment · 7 years ago

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!

Comment · 7 years ago

Hi there, I lead product at Dgraph and I'll be happy to answer any questions you might have.

We're very happy we're finally able to share our fundraise, and this is just the beginning of many more features and improvements!

PS: we're hiring ;) https://dgraph.io/careers