TLDR; DGraph makes a high quality wife, but a terrible girlfriend.
Everyone has different backgrounds, so here is mine:
I’m a senior dev freelancing to support ~5 small to mid size companies (100k/year to 20 million). Some of those projects are the kind that could explode in growth. I’ve stood up close to a dozen websites in the last 2 years from scratch and shipped 4 different react-native applications. The name of the game for me is fast scalability. I use dgraph cloud, and mostly use the graphql API for one project. I’ve played with Neo4j before, but mostly I’ve done SQL.
For me, I obviously want it all. I want a scalable backend that requires little to no code from me for the core operations. I want the ability to customize and plug into that backend when I need it to.
RESPONSE SUMMARY
DGraph makes a high quality wife, but a terrible girlfriend. It has some great virtues but you have to invest a lot into it to get them. It’s still too needy and picky, so unless it’s exactly the solution you need, it’s not worth dealing with it’s idiosyncrasies yet.
I intend to only use dgraph on some projects for the foreseeable future. The projects must both need high scalability and have extensive relationships that are critical to core operation of the project. If I can get away with Hasura, I will continue to use Hasura for the time being due to it’s extra polish and significantly better developer experience.
I want to recommend DGraph to people. I have a consulting company that I work with that I’d love to get to use dgraph instead of Hasura beacuse it would simplify many of their problems. But I can’t because Dgraph is not developer friendly.
To use DGraph more I would need to see:
- Filtering across relationships (in graphql)
- Bulk Update across relationships (in either, but preferably graphql since it’s cleaner than DQL)
- Something like SQLs cascade on delete/update system so I can enforce data integrity at the data layer
To recommend DGraph more I would also need to see:
- the graphql for dql tutorial be improved to help more than junior developers (sub-select queries, sub-select in mutations, group by, windows, indexing, rank)
- Improved DQL docs for upserts OR add sub-select statements in graphql (preferred!)
- Faster uptime to first external query
- More in cloud editor help & messages for when certain changes will orphan data or cause negative side effects. IE - "You dropped the column “oldDataColumn” from your schema, would you like to remove it from your DQL schema and also remove all predicates for that column?
- Better lambda support. Currently lambdas are slow and unwieldy. Hasura has a simple UI that would help a ton.
Also, I’d be happy to do some User meetings to discuss things more in depth, walk you through my development experience and it’s frustrations, brainstorm ideas, discuss training materials or help almost in any other way.
I’ve already mostly committed a pretty large project to dgraph and would love to be able to use it for more projects and recommend it more. It could easily become my go to backend for everything.
DETAILED RESPONSE
To help out I’d like to rate DGraph compared to both Postgres, and Hasura
Scoring PostgreSQL vs Dgraph (out of 5)
Basic CRUD:
Dgraph: 4 Postgres: 5
Relationships:
Dgraph: 5 Postgres: 3
Data Maintenance:
Dgraph: 2 Postgres: 4
Data Validation:
Dgraph: 2 Postgres: 4
Data Transforms:
Dgraph: 3 Postgres: 5
Scalability
Dgraph: 5 Postgres: 3
Explanations:
Basic CRUD
Pretty close here, the -1 to dgraph is mostly due to having to maintain a giant schema file instead of being able to break things out into separate files
Relationships:
Dgraph wins here, and this + scalability is the reason I’m using DGraph still even with it’s limitations
Data Maintenance:
This is painful in DGraph. I shouldn’t need anything more than an editor to maintain my data. I have to write scripts way too often. Bulk updates, bulk deletes, renaming columns, moving/copying data from one column to another. Even using DQL I still find this obnoxiously painful too often, not always, but way more than it should be.
Data Validation:
Mostly minus points here because of a lack of more find grained data types, and any form of constraints to ensure data continuity. Please don’t improve this too much until after making Data Maintenance better.
Data Transforms:
There are no triggers, except Lambda, and Labmda is a non-performant pile of avoid me right now. Also, doing any sort of data transform across a table requires a script. Doesn’t work good in DQL or GQL. Say what? We have a graph database that excels at relationships and none of our core query languages support maintaining or working with your data across those relationships.
Scalability:
Yeah, Graph databases win here big time when dealing with large datasets. Only applicable to larger clients. Since my project is still in-progress I’m just hoping dgraph scalability lives up to what it feels like it should be capable of.
Scoring Hasura Cloud vs Dgraph Cloud (out of 5)
Authentication/Authorization:
Dgraph: 3 Hasura: 5
Side Effects:
Dgraph: 3 Hasura: 5
UI Console vs Dgraph Cloud Console
Dgraph: 3 Hasura: 5
First Time Setup:
Dgraph: 4 Hasura: 4
Graphql API Quality:
Dgraph: 2 Hasura: 5
Explanations:
Authentication/Authorization:
-1 to DGraph because Hasura’s permissions UI is phenomenal. Dgraph’s is good enough, but if they were to copy Hasura’s permission mechanism, that would be way better. -1 Because it wasted 4+ hours of my life trying to get my first query working externally. Being on DGraph cloud I was missing adding an SDK key. Finally found the docs in a completely different section of the website, buried. Write a guide: “Getting your first external query working”, or even better allow me to have my server in “dev mode”, and give me a better error message with a link to the docs.
Side Effects:
Mostly because DGraph’s lambda system is painful. I get one tiny little editor in the cloud, or I have to set up a new custom build and upload to an endpoint. If I’m going to do that I’ll just do it on AWS or something where there is already a lot of tooling support. Especially because lambda’s on dgraph so far are slow.
UI Console vs Dgraph Cloud Console:
Hasura’s is more polished. DGraph still has one giant schema file, the inability to delete a type and all it’s child predicates and their data, one giant lambda file. Way too much padding so I have to scroll all the time. No separated permissions or relationship definitions.
First Time Setup:
They’re both pretty equal here. In Hasura you have to setup your DB separately, but you get a UI that can help you start building your schema effectively and with separated tables.
In DGraph the Graphql Schema is a lot nicer for modeling data than SQL, no separate database, but you have one place for one giant schema file which leads to a LOT of scrolling. Plus, putting a comment in the bottom of the schema file for your auth stuff? Seriously?
Graphql API Quality: I actually think that DGraph has more features overall here, but the big reason I ding DGraph so hard is they are a Graph database that doesn’t allow you to walk relationships on a filter. Cascade fits some use cases, but not all (like mutations). Hasura only works on SQL databases, but still allows you to walk across relationships.