| I'm building a product that does graph analytics on top of DGraph. Some constraints we have:
* We ingest what some may consider a lot of data - on the order of terabytes a day. This can be 10's of thousands of writes per second. * We need transactional logic. * We want to analyze that data as it comes in, so think 10x reads for every write. GraphDBs out there didn't seem like they would cut it. I eliminated almost every database due to: * Bad licensing * Incapable of scaling writes horizontally, or generally anding tons of rights * No ACID transactions Most graphdbs out there had at least two of these issues. DGraph so far has worked really well. We aren't sending it the full load of data yet, so there's still a question around that write load, but at least it's designed for that, and initial numbers have been promising. The fact that it's liberally licensed, has a really good pricing model, has strong community support, good docs, etc, has made me glad I chose it. The roughest part is probably the query language, because it's bespoke and therefor ends up having weird unexpected behavior sometimes. Now that it supports GraphQL that should be less of an issue. |