Where graph data modeling shines using Neo4j
Nitin Pasumarthy | TrustRadius Reviewer
August 24, 2017

Where graph data modeling shines using Neo4j

Score 10 out of 10
Vetted Review
Verified User
Review Source

Overall Satisfaction with Neo4j

I am using it as schemaless data store to persist my knowledge graph. As the name indicates, neo4j is a perfect choice when the query pattern is about finding the relationships between entities. I evaluated it with similar use cases, besides knowledge graph, where finding patterns was essential. It is a very good choice when joins are very common in a relational store. As the data is completely materialized, all joins are in constant time which tremendously improves query performance out of the box without extra system design.
  • When joins are a common in a relational store, switching to Neo4j is better
  • When pattern matching and surfacing interesting insights is the goal, neo4j's cypher is pretty powerful
  • When schema is not completely known beforehand and needs to be evolved with time
  • Better support for aggregation queries
  • Drivers for Spark where ML or more computationally heavy jobs are to be performed
  • Native support for complex properties for nodes and relationships
  • It has a very positive impact due to excellent community support
  • Helps us iterate our ideas much faster
  • Easy to use as it a very natural way to think of data - nodes and relationships
  • Use years of existing graph algorithms on large scale
Neo4j is a graph store and has different use cases compared to another NoSQL Document store like MongoDB. MongoDB is a bad choice when joins are common as existing operators for joining two documents (similar to tables in a relational store) as Mongo 3.5 use SQL like join algorithms which are expensive. MongoDB is a great choice when distributed schemaless rich document structures are important requirements. Cross document transaction support is not native to MongoDB yet, whereas Neo4J is ACID complaint with all its operations.
  • When pattern matching in data is crucial
  • When data exploration is common query pattern
  • When a graph algorithm solves the problem better at scale
  • When evolving schema is important
  • When constant time joins in a relational database are common
  • When schemaless transaction support is required
  • When thinking in patterns is a more common way to derive insights from the data