Where graph data modeling shines using Neo4j
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.
Pros
- 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
Cons
- 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.

Comments
Please log in to join the conversation