Hi all,
What is the version targeted to be production ready? 1.0? And what is the expected ETA for it?
Additionally, it’d be great to know if there are companies deploying dGraph at the moment.
We’ll consider Dgraph to be production ready once it has been in use for six months in a production environment.
There’re a few companies who’re currently trying out Dgraph in their production environment. We do suggest people use Dgraph in production.
1 Like
Was wondering if you could share companies which are using dgraph in production??
We are exploring production ready graphdb. I know neo4j has good deployed base, but lack of a production ready go driver made us explore us options.
I just had a brief look at dgraph, really like the active community base plus an enterprise version. However, I didn’t see any info about it being deployed in production to give us some confidence of the product quality. Really appreciate some info on this.
Dgraph is being used by an active base of users and quite a few companies that we know of have built their apps on top of Dgraph and running in production. So, I’d recommend using it!
@mrjn Are there any testimonials or public info about which companies are using dgraph in production? I’m in the same boat as Amit, Dgraph seems very attractive but its hard to trust claims of “production ready” without endorsements from third parties.
2 Likes
I picked some users who filed issues on GitHub in the last year for feedback on slack. Some of them didn’t reply and few of them are still testing it out. Based on the feedback of people who are using it in production, Dgraph is a great project but not production ready for critical services
Ever since Dgraph hit 1.0 it has been much easier to work with. We started long ago with it, and the amount of breaking changes at the time were a stress on us, but it has paid off. I Highly recommend Dgraph, and have been very impressed with it’s speed, and server simplicity. I still think there are some devops things (like auto backups with auto compilation of the separate server data), but I am sure that will come - willcj33
I'm using it for very simple dependency tree queries, we chose dgraph because of the low latency queries. we're using it in production
My recommendation would depend on the type of usage.
we've hit a lot of snags when using it in a clustered way. we have 3 nodes (zero+alpha) and we had problems with the cluster mechanics
things like, one node being slower and that bringing the entire cluster unresponsive, probably due to enforcing consistency
we also had problems where, one node was down and the other nodes could not respond to queries. things like this, we found it a bit frail
when it's working nice, it's a charm, so overall we're happy - mrosa
we have been using it in production for a few months now
They seemed to have fixed most of the memory leaking issues and we also have the server on a 64GB ram machine now so that probably doesn’t hurt
They main annoying thing at the moment is the in-ability to write to the same node / index concurrently. Most other databases I have used can handle concurrent writes, even if it means queuing them up
For us, we have to have a retry strategy for all of our mutations to ensure they get stored since we can have multiple reasons that the same names are to be updated (edited)
As far as query power and speed, we could not be happier about Dgraph
So if you aren’t that write heavy, I would recommend Dgraph easily
If you are write heavy, just know that you will have to do some extra - Eric Hangman
Dgraph is a great platform however it has a ways to go to be truly production. We've decided to use Dgraph on 3 projects in production and we've gained many benefits from it. However admittedly that has come with some struggle. My opinion is: a) GraphQL+ leaves a lot to be desired, the new Cypher implementation is supposed to make that a lot better, b) the speed and performance is exceptional, c) the idea of schemas and types could be improved however the pluggable tokenizer option in Dgraph makes it easy to work with.
Having worked with Neo4j, OrientDB and other graphs, I still prefer Dgraph. - dblaise
we still face problem
primarily on the dgraph performance
when the data grows significantly
the speed also drop sharply - calvindro satyagraha.
we are moving away from Dgraph as we had faced lot of issues related to leader not being elected... Queries getting stuck... Cpu at times high...
It sits with one of our chatbot application but problematic at times. We have started implementing it from 0.7.7 but unfortunately didnot find it stable until now - Ankush
its not ready for the production
I had to write a lot of sync related code to make it somehow work in prod as we had already invested and structured a bit of our code pipe
I have already started figuring out options - Akshay Deo
I would recommend using dgraph in production. Here’s why I think dgraph is a great choice:
Distributed (with transactions) capability out of the box, even without an enterprise version
Development team that moves at high speed and is very responsive
Dgraph team commitment to development of their product out in the open and community involvement
I would also say I think v1.0.5 is a great release. Right after v1 there were a couple bugs that needed to be addressed, but with each release those issues are going away. - tamethecomplex