campoy

Hi there, out of curiosity what do you mean the data is stored multiple times for speed?

We (I work at Dgraph) have data redundancy when you have multiple replicas for a given group - but that's an optional feature.

Thanks!

That's great to hear! Let us know if you need any support with Badger

Hi there,

Head of Product at Dgraph here. Our license is Apache v2 for most of our source code.

Only our enterprise features are licensed with the Dgraph Community License [DCL](https://github.com/dgraph-io/dgraph/blob/master/licenses/DCL...).

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

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

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!

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!

Thanks for sharing these, cool handle name btw :)

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]

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

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]

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!

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

I'm a Google employee and you made me LOL hahaha

well thanks

I totally agree with you on this. The code for all three languages is clearly not optimal.

I wonder how much of this performance difference is C++ being very good at optimizing your code rather than the runtime being more performant. I don't have any numbers, but I feel like that's not a negligible factor.

I know, and that is exactly my point.

Micro benchmarks across languages with code that doesn't do anything interesting is pretty pointless IMHO.

Also, am I a twitter developer advocate now? what is that?

I don't care about micro benchmarks ... but if you're gonna do one, make sure your code is decent.

By replacing the Go slice declarations (var x[]int64) with (x := make([]int64, 0, 1000000)) you'll get an algorithm that in my iMac runs much faster:

- your version: 4.93s user 0.28s system 165% cpu 3.151 total

- my version: 1.93s user 0.04s system 168% cpu 1.165 total

EDIT: I'm sure this happens with all the examples, and that's exactly my point. What is this exactly microbenchmarking? Bad programs?

I'm happy to give you credits to host it on Google Cloud Platform :-) Shoot me an email [email protected]