Generally you could say that application logic/queries being more concerned about links or linked entity attributes than direct entity attribute values is a sign that a graph DB may be a good fit. I'd say about 50% of db using apps are like this. You can get an idea by looking at their benchmark workload descriptions.
If you mean fully RDMA offloaded huge cluster DB systems, then I don't know the answer but suspect this kind of thing hasn't made it to industry yet:
"GDA internally uses a distributed hashtable (DHT) to resolve dif- ferent performance-critical tasks conducted under the hood, such as mapping application vertex IDs to internal GDA IDs. For highest performance and scalability, GDA’s DHT is fully-offloaded, i.e., it only uses one-sided communication, implemented with RDMA puts, gets, atomics, and flushes. Its design is lock-free, it incorporates sharding, and it uses distributed chaining for collision resolution. To the best of our knowledge, this is the first DHT with all its oper- ations being fully offloaded, including deletes. The DHT consists of a table (to store the buckets) and a heap (to store linked lists for chained elements)."
- Feature generation for machine learning model training (particularly popular with fraud detection at financial institutions) - social networks (think LinkedIn or Facebook) - supply chain analysis and optimization - healthcare patient data analysis (looking at similar patients to recommend treatments or do large scale analysis) - user identification (eg taking lots of data points and tying to a specific user). There’s a more specific name for this I can’t remember off the top of my head.