You Should Use A Graph DBMS If...
You're not sure what the medium-term needs of your data store will be. A Graph DBMS will allow you to be agile .
You have multiple redundant data stores and applications that can't talk to each other. A good Graph DBMS has the flexibility to intermediate between applications and to be your store of "Master data".
You're facing a data migration that's going to cost tens of thousands of dollars or tie up resources for many months. With a properly-implimented Graph store you'll never have to migrate again.
You're looking to create something new. A graph DBMS may be the only way it's possible.On a more technical note, you should consider a Graph DBMS if...
- Your RDBMS schema is bigger than a white board.
- You've denormalised your schema so much that the redundancy makes you cringe.
- You find yourself creating materialized views or other intermediate data structures just so you can get adequate performance.
When NOT to use a Graph DBMS
If you know the job can be done with a Relational Database, then that's what you should use. It's a well-understood, conservative technology that will give you more choices, more tools, and more resources.
If your needs are for simple data collection and retrieval at high volume - use one of the NoSQL Key-Value or Document Stores.
If you want to perform batch-based, computationally-expensive tasks over simple, unconnected data structures - use a distributed processing framework (e.g. Hadoop) with support for distributed data storage.
But if you want stretch the bounds of what's possible with your data - take a closer look at GraphBase.