Dgraph Reviews

The GraphQL with a Graph database under the hood is the best feature. It is easy to use, and you can query complex relations quickly and with ease.

The product is not quite mature yet but does everything better than Firestore out-of-the-box.

Once you get it going, you will never want to return to Firestore again. It is also so quick. Graph databases are the future, and DGgraph is the full experience to compete with PostgresSQL

I want to easily and quickly launch my website without writing custom server code or middleware. It is ready to go, quick, and relational.

Dgraph is the best backend as a service tool I've used. The most powerful feature is that you can upload a txt file with your GraphQL types, and it'll generate a GraphQL API that is backed by an insanely powerful graph database.

With Dgraph, complex and/or slow SQL JOIN queries are replaced by simple GraphQL queries that perform well regardless of the relationships that exist in your schema. You don't need to worry about n+1 queries anymore.

There are still a few things missing from Dgraph's GraphQL implementation. Some of these issues are being worked on, but others I'm not sure. You can create custom resolvers with Dgraph pretty easily using their DQL language (Dgraph equivalent of SQL that interacts directly with the data); however, currently, you can't create custom mutation resolvers with DQL. Really there just needs to be more transparency from the Dgraph team about what's on the roadmap, and ideally, they should allow customers to vote on what features to prioritise.

Another area where Dgraph is lacking is that admin UI. Ideally, I'd like to be able to configure a Dgraph instance without writing any code, i.e., I'd like to be able to configure auth rules for a GraphQL type by clicking a few buttons.

I'm using Dgraph to build a backend for an educational product that makes heavy use of machine learning. Analysing the relationships between entities in our database is essential to our ML pipeline. Because Dgraph allows us to iterate on our schema without worrying about performance problems or getting stuck on query optimisation issues, then we are able to put more focus on shipping code that creates customer value, rather than wasting time writing what is essentially boilerplate code.

I have been using Dgraph for more than a year, and I love it. It's fast, stable, and straightforward. The customer support is incredible, very responsive, and open to taking up on bugs and feature requests.

NO Downsides on the Dgraph, improving Ratel features will give a quick start.

We are using Dgraph to create the dynamic relations and use that data to find patterns/relationships between nodes and analytics.

It has excellent performance, it's open source, and the team has a good culture.

Getting started with it was relatively painless (self-hosting could be easier).

DQL is fantastic if you need the additional capabilities it offers over GraphQL

It's also written in Go which is the same as a lot of our platform which is beneficial to us should something take too long to be fixed or implemented, we could contribute.

The overlap in their documentation between products, although this is being updated soon to be more explicit.

I'd like a little more transparency and feature parity between the different products they offer and their respective roadmaps.

Version numbering uses a naming scheme which bothers me as its confusing when coming from the Go community and doesn't follow traditional package naming conventions which favour SemVer. I understand the decision they went through to do this... but I still don't like the package version naming of their clients etc.

We connect incredibly disparate and highly interconnected data across collectible asset classes, including qualitative and intangible information like ownership sentiment.

Dgraph did what it was supposed to and let us model the data in a way that was easy and flexible to manage with out platform.

A very accessible graph DB solution. Ratel dashboard at play.dgraph.io allows one to become quickly familiar with the syntax. Set up on k8s. The team is very responsive and helpful in the case of issues or inquiries. Recurse option to return nested levels in the tree. Compatibility with Go and tracing to identify bottlenecks. Metadata on the queries to see how many nodes were touched.

They don't mention (in their paper at least) where they use DFS vs BFS to optimize different queries. It would be interesting lo learn more about this and potentially have control over this in the form of a variable. When doing complex queries on many nodes response times were inevitably high; I'm wondering if there could be a place for some more optimization there.

We use DGraph primarily for our authorization as well as for authentication through a designated microservice written in Golang that implements a REST protocol to interface between DGraph and the rest of our infrastructure. It's data structure is perfectly suited for the very hierarchal nature of our large enterprise clients and out-performs a traditional SQL or NoSQL dB for this reason.

The Dgraph product is super lite weight and very fast in performance in querying across millions of edges. Dgraph Team is a very dedicated in solving the needs of the us and helping us in making sure our product is build right way and providing insights and improvements. This help us in a big way in using Dgraph in our solutioning. Dgraph support is exceptional and many thanks to Daniel Mai from support team. Very professional team and smart engineering team.

Honestly nothing of the sort to dislike. Any software has a bug popping up and Dgraph Team is doing excellent job at squashing them as soon as we report it .

It helps in solving Identity resolution of the customer by combining multiple identifiers across devices and touchpoints with data points collected along the way to build a cohesive, omnichannel view of consumers, so we can reach them when and where they are most likely to engage along the sales funnel.

I am a big fan of DQL. At Mooncamp we use it in every part of our application, and it feels like Dgraph built the missing parts to GraphQL. Furthermore, I love Dgraph's facets. We use it to store information such as the order on edges. This used to be very complicated to model in relational databases and is now so easy with Dgraph.

There isn't really much to be honest. If I had to name something, then I would like to have some improved data export functionalities within Ratel UI.

An easy way to start using Dgraph is their new service Slash GraphQL. I personally believe the future of software development will be based on services like this and would strongly recommend giving it a serious try.

We are building a product with a highly branched data model. But this kind of data model is difficult to model in relational databases. Dgraph makes relations between nodes far more accessible than a traditional relational database could and offered us a new mental model on how to think about how we structure our data. Suddenly connections between nodes weren't an obstacle anymore, but are encouraged by the database.

Furthermore, var-blocks helped us solve some complex issues such as authorization and deeply nested filter queries.

My favorite part of DGraph is that they use GraphQL +/- as their query language because I'm able to easily get back exactly what data I need without having to write complex joins.

Their Ratel interface for running queries was thoughtfully designed creating an excellent developer experience. Having the ability to choose whether we see our query responses as JSON or a visualized as a graph has made a huge difference in our productivity because we're able to clearly understand the implicit relationships in our data.

DGraph has a very responsive and helpful developer advocate team who is always willing to help. They've invested a lot of time into making quality documentation that is easy to get started with and has remained supportive as I continue to learn more.

Honestly, I can't think of anything I don't like and haven't experienced limitations.

We have complex data sets that require very clear relationships and we couldn't risk inferring data connections with foreign keys. We needed the ability to query our data easily so DGraph was a natural fit for our product.

We chose DGraph because of its performance, reliability, and scalability benefits which have all met our expectations.

Dgraph has been absolutely instrumental in solving complex issues on widely used internal tools within Comcast. Having full GraphQL compliance on top of DQL (Dgraph Query Language) has made building robust dashboards with ease without sacrificing performance. One of our hardest problems to solve was building a la carte queries with complex reverse references and deep relationships. With Dgraph it solves all of those needs without having to build out custom solutions or middleware.

Being able to upsert lists with live / bulk loader would be very helpful. Having to replace lists edges requires doing a separate transaction first. More control over memory allocation would also be helpful in some circumstances.

Make sure you have sufficient memory!

- Complex entity relationships

- Easy reverse reference queries

- Very easy schema management including index management

- Blazing fast!!

- Ability to build a la carte queries with ease

In our experience, Dgraph has made graph databases accessible for everyone and has convinced us to migrate our mixed-use databases to Dgraph. The documentation is great, but the community forum is even better! We have regular contact with the development team on specific feature requests. The pricing is also very attractive for smaller projects; even if they grow bigger it will still be affordable. The free tier makes it easy to start small and expand when your project is maturing and getting new customers.

Before SlashQL, the Enterprise pricing model was too expensive for smaller companies. When we contacted Dgraph to get a custom quote, they asked us to be part of their process to bring up SlashQL. When working with personal data, certain feature like encryption at rest and regulars backups are crucial for the infrastructure. The old pricing model made it difficult to really embed it into our business.

Overall we are very happy to collaborate with Dgraph. It takes some time to adopt a graph database, but if your company is willing and ready, Dgraph/SlashQL will help you with the migration. We used noSQL and SQL databases for our use-cases, but we ran into limitations (wether it is a technical restriction or lack of knowledge on our end) and had to solve it in a non-favorable way. A graph database just works very well for us and Dgraph made that easily accessible for us.

We use Dgraph as our all-purpose database for aggregating lifestyle data (mixed time-series and descriptive models) to offer a personalized and responsive behavior change program to our customers in research and soon to the public. The addition of GraphQL support to Dgraph in SlashQL makes it easier for our partners to integrate with us because they can determine the data structures they want themselves. In turn, this makes it easier with a smaller team to provide a good service to (potential) business partners or end-users.