That can be non-obvious, so fair. We (graphistry) get pulled into a lot of investigative scenarios -- account takeover (web logs), malware/phishing analysis (host/network logs & feeds), AML, claims fraud, etc. I found the problems being solved to be some combination of: awkward to express with SQL, too slow to run in a RDBMS, or hard to visually explore relationships/correlations.

Examples:

=== Shortest Paths

1a. Referral: "Who on our team connected to which leadership at Apple?"

(target:Company[name="Apple"])<-[_:Leadership]--(champion)--[]-->(us:Company[name="myCompany"])

1b. Supply Chain, AML, entanglements...: "How are these companies related, even if 5 companies away, and across all sorts of relationship types?"

(a:Company[name="a16z"])-[r:1..3]-(b:Company[name="juicero"])

=== Neighborhood (incl. multi-hop):

2a: 360 context on a security/fraud/ops incident:

(hacked:Computer[ip="10.10.0.0"])-[e:Alert]-(metadata:)

+ (hacked:Computer[ip="10.10.0.0"])-[Login]->(u:User)-[e:Alert]-(metadata:)

2b: fraud rings:

(fraudster:clientIP)-[login:http]-(b:Fingerprint)

+ (fraudster:clientIP)-[x:http[method="POST"]]-(p:Page)

2c: Journeys (customer, patient, ...)

(a:Patient[id=123]-[e:1..2]->(b:)

=== Whole system optimization / compute:

Personalized pagerank, supplychain optimization, business process mining, ...

===

The above can be extended, such as by adding in compute (correlation, influence scores, ...). That feds into viz / recommendations / decision making.

or: Not all uses of graph are end-to-end. We often get used with a graph db to improve understanding it (our viz scale 100-1000X over the tools here via GPUs)... but folks may instead plug their graphdb into a tabular frontend. Or use us with a tabular system like Splunk/Spark/Elastic. So the above can be hard to write in Splunk/SQL, or slow to run, or hard to visually understand.

This may not be a canonical application of a data model, but expressing graph queries using "Cypher", the graph query language invented by Neo4j, is very intuitive to my mind. I find the use of ASCII art to help visualize the relationships welcome.

For example, say we have a graph of movies, actors, reviewers, producers, etc. Here's Cypher query that returns the names of people who reviewed movies and the actors in these movies

  MATCH (r:Person)-[rev:REVIEWED]->(m:Movie)<-[:ACTED_IN]-(a:Person)
  RETURN DISTINCT r.name AS Reviewer, m.title AS Title, 
                  m.released AS Year, rev.rating AS Rating,
                  collect(a.name) AS Actors

Another example: You want to know what actors acted in movies in the decade starting with the year 1990

  MATCH (p:Person)-[:ACTED_IN]->(m:Movie)
  WHERE 1990 <= m.released <= 1999
  RETURN m.released, collect(m.title) as titles, collect(p.name) as actors
  ORDER BY m.released

I'm new into this "knowledge" space - but I've stumbled upon structr.com - It's open source - you can use this as an extremly flexible content management system for buisness processes and stuff like that - check out their website - however can't tell you much more it's on my todo list.

RDBMS are developed with joins in mind, but also die of the complexity involved resulting from these joins (both from developer perspective, as well resources.)

Now imagine your join to become a primary perspective to look at your data. Then you'd see creditcard transactions (who buys what when?) or maps are better represented as a graph. I know for example TomTom uses neo4j to validate map edits in production.

Say you have transactions which follow a complex supply chain... Sure you can reconstruct the path taken using recursive SQL, but you're also joining lots and lots of things together at runtime.

In a graph database, you've effectively taken your 'join' penalty at the point of ingestion and you have an expressive query syntax to describe the pattern you're trying to match.