My single node setup was about the same as yours, one alpha, one zero with default config on a HP Spectre.
1 TB SSD, 16GB memory, i7 quad-core. I think LRU was set to 2GB as well. Pretty much standard I would say.
Cluster setup was the docker-compose with 3 alphas, 3 zeroes + ratel + ngnix load balancer dispatching each request to one of the three alphas.
The low latency was measured on many single transaction of mixed read & write, just as your typical web application would do so no batching nor sequential upserts.
Sequential inserts seem to cause some problems in DGraph, one way or the other, I think there are a number of reports very similar to yours. Also, you have to be mindful of memory configuration and some really weirdo stuff on sustained writes. If this issue is correct, you can expect about 10k online transactions per sec so technically your insert should take no more than 10 - 20 seconds, plus some overhead for adding edges, which raises some really, really hard questions.
=> each tnx searched for V1 and V2, then added edge between the two V1 → V2
This took ~22 minutes!
On just 88k nodes? This is unreal, really, and I don’t think I have ever seen that before.
A few days ago, I did an evaluation of ArrangoDB, and given your node is sufficiently powerful, it runs relatively fast and scales nicely and their cluster setup is among the fastest I have done in quite a while. The enterprise version is free, but you need to claim your key and add it to the deployment.yaml. They claim some substantial performance gains over Janus and can handle 1Gb/sec write load, given a big enough cluster size, so I would do a comparison.
That said for my cluster deployment, I ran into some problems, reported a number of issued, asked in the forum a few times, got told I should solve the missing security myself, emailed DGraph twice, never got a reply, and you know, meanwhile I have given up on it. They have some good ideas, and I tried hard to make it work, but for us, it just doesn’t work in practice.