RDBMS are now the de-facto industry standard and they shine in calculations through BIG arrays of data packed into rectangular tables (consider mega- hyper-Excel on steroids). But neither real world nor business logic is rectangular by their nature. The World consists of flexible structures like lists, like trees (be it a plant, or organisational structure, or tree of possible decisions), like networks and lace, or - what a horror! - like fractals. RDBMS, with its tabular rectangular nature, is able to emulate these with its tables - but it requires deep and complex programmatical magic, which also involve complexity, computational and human resources, and... software errors.
Being a native graph database, Neo4j allows you to reflect complex real-world graph structures of entities and their relationships in an easy and natural way, close to 1:1 mapping - and thus, avoid bulky emulation of ethereal spiderweb structures with heavy rectangular bricks made of SQL. This allows you to make your systems faster, more responsive and smarter - because they reflect the reality better. Also, graph data model is much agiler than relational and tolerates many real-world conditions which RDBMS can not.
Using Neo4j since 2013 I confirm all the above myself. It is perfectly suitable for being a kernel for enterprise Master Data Management, integrating different business systems around it. Neo4j is perfectly suitable for modern microservice architectures of enterprise solutions, this technology is also native to it.
And the price-performance ratio is impressive. Neo4j is very, very fast, and (with Enterprise license) it smoothly scales horizontally (you also get HA as a bonus). Databases scaling a billion of nodes and several billions of relationships are perfectly realizable (I personally have used a database of about 200 million nodes and Neo4j scale extremely well - it's performance does not depend on the size of the database, only diameter of the graph really matters).
What captivated me the most is how easy and natural graph technology allows you model complex realities and discover non-obvious interconnections and relationships between the entities, together with hidden patterns of facts. OLAP cubes too are graph structures. after all.
Technology is new - but the learning curve is not too steep, as soon as you catch up with this new, different graph attitude. Also online support from the community and directly from Neo4j team members makes learning Neo4j a fascinating and pleasant experience.
Neo4j is industrial grade, commercial quality product. But it is at the stage of rapid development just now, upcoming version 3.0.0 promises new features and performance boosts. Also the graph query language - Cypher - is under extensive development, new "sugar" is being added to it together with performance enhancements. So it may be hard to choose which version to take for you project - more mature with fewer features, or the newest and powerful, but not proven bullet-proof yet?
Anyway, I can not call it a disadvantage, you just need to think two steps ahead, not one.
In my projects, Neo4j was used as a master storage for business data migrated from legacy inherited systems, including CRM data, product catalog, provisioning, and billing. Observed benefits were:
- Neo4j allows easy data model reengineering, which brings new business value to inherited datasets, and gives abilities to interrelate previously isolated chunks of data,
- makes software development faster and easier - it eliminates the so-called Object-Relation Impedance which is typical to systems where RDBMS acts as a persistent storage of complex business data objects. Bulky and unwieldy and cumbersome Object-Relational-Mapping (ORM) persistence software layer (which in fact does not create business value) is replaced with lightweight and natural Object-Graph-Mapping (OGM) and this and it saves a lot of man-hours of development with better business results,
- Neo4j and graph data model tolerates "dirty data" and non-critical software errors much better than RDBMS; it is perfectly suited for Agile development process when requirement changes are popping out almost daily - but with graph, these changes do not demand re-engineering of the whole data model, only isolated parts of graph are affected and you can easily avoid crashing your previous development efforts.