DGraph for smaller projects / low-resource contexts

[BenW]

@iluminae

The standalone image has 1 alpha and 1 zero - if you hit any corruption, the whole cluster is dead. With 3 alphas and 3 zeros, a corruption can be fixed by removing the effected node and adding a new one.

If you don’t care if your cluster OOMkills and possibly looses all data to corruption, then you can run whatever you want - but that is unpalatable to most running a real app.

This is a problem that is limited to the standalone? Wondering why an OOM situation causes unrecoverable data corruption? Is it because Dgraph currently has no solution in place to prevent data corruption, or is it because the solution is actually sharding and replication (which you don’t have with a standalone node)?

EDIT:

@maaft

Hi! We’ll probably adapt ent on-top of a postgres database for our usecase. Ent already integrates nicely with graphql. And although the boilerplate overhead is significant, system requirements are suuuuper low.

@maaft Did you look at Neo4j? Their GraphQL offering is pretty good, and auto-generating. Managing a Neo4j instance involves more manual work with configuring indexes etc, and the performance is slower but it seems like the best alternative to Dgraph right now.

The lack of clarification from the team about what causes these corruption issues, slow inserts etc. and lack of roadmap for how and when they will be fixed is forcing me to look at alternatives. It’s really troubling.