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.


Comments

do magical things with your data