A go-to solution if a graph db is actually needed
Use Cases and Deployment Scope
We needed a graph database to record relations between different corporate entities. We want to track relations like beneficial owners, subsidiaries, related parties, etc. There could be many edges and the edges needed to record various metadata about the relations like the date that relation became significant. Importantly, we wanted to be able to run relational queries that would be tricky with postgres.
Pros
- Easy to query deep paths (for Ultimate Beneficial Owner)
- Storing metadata for edges
- Easy detection of obscurely connected entities
Cons
- We felt we could only scale easily vertically
- We felt limited by Neo4j's hosted machine options
- Limited constraints to enforce relational patterns
Likelihood to Recommend
When we had to calculate ownership of deeply nested subsidiaries, Neo4j was awesome. Using Cypher’s variable-length paths (-[:OWNS*..10]->), you can write a script that traverses the entire tree and multiplies the "metadata" (% ownership) along the edges in a single pass. In Postgres, this would require a massive recursive CTE that is difficult to debug.
