I'm starting to think that a lot of my tables could be replaced by only a graph db:

For example: I have 4 tables: accounts, votes, posts, relationships

but I can represent all these in a graph table with different edges,

NODE1 -> type of relation -> NODE2
account -> vote_+1 -> post
account -> wrote -> post
account -> friend -> account2

is there a difference of performance or other between them?

  • 4
    Hard to say... I don't know how you're using this data. You might have to try both out under different sized loads and measure which does better. Commented Jun 13, 2011 at 17:41

5 Answers 5


you can always represent relational data in graph form

the key is how are you using the data - mostly transactional updates, mostly graph-traversal queries?

if you have the time, do the conversion and profile your most common operations on both DBs


Actually, more than being graph DB it, what you describe is more like triplestore.

Triples subject -> predicate -> object, is what you're calling node1 -> type_of_relation -> node2.

If you combine that with inference engine, you can have very powerful tool. You'd be able not only query direct relations, but also implied relations. Like for example if you define rule like:

A -> grandparent -> B := (A -> parent -> x) && (x -> parent -> B)

They you can query grandparents, but you don't have to store that information in the DB. Of course this is very simple example, you can use it to build rather complicated relations.

The query language for triplestores is SPARQL, which is roughly based on SQL, and is quite simple to understand.


Is it a live system? Do you experience performance problems?

If no, don't bother changing everything to a graph database. If you don't gain anything at all, but instead take a lot of time away from other tasks, is it worth it? No.

If yes, identify (profile) whether or not it is the database being the problem. If it is, do some tests and check whether or not a graph database will be faster.

Don't just "optimize" without actually knowing whether or not it is worth it. The most important thing is to have a good architecture, and then you can later see if there is a problem. First when you find the problem, you start finding a better solution.

  • The question seems to be suggesting an anti-optimisation to me - it's optimising a kind of design/maintenance overhead if anything (describing the logical database structure to the DBMS), not performance.
    – user8709
    Commented Jun 13, 2011 at 22:27

A many2many relationship helper table (a table with just two foreign keys) is a digraph adjacency list. A graph db may be advantageous if you have lots of m2m relationships, however it comes with the same cost as an m2m, which is always a bad thing unless they are truly necessary.

For example, account -> vote_+1 -> post and account -> friend -> account2 are m2m relationship, but account -> wrote -> post are not.


Absolutely yes. GraphDB allows you to speed up a lot many operations such as traversal. But the gain depends by the specific use case.

  • 1
    "Absolutely, but it depends." :)
    – Ed Brannin
    Commented Nov 13, 2011 at 3:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.