For shallow or narrow queries of the graph this is the way to go.
But for deep and broad queries, if you want to perform some valuable analysis that involves traversing the graph some non-trivial distance from the point of origin, that's where PostgreSQL is going to let you down and you would probably be better off picking a more appropriate tool.
Same question though: How do you want to query your graph, and are you willing to limit yourself to not querying it in a certain way?
I'm pretty sure you can get comparable performance from a graph in SQL if you make sure you have covering indexes for the Node ids and the edges/adjacency list table.
This may be implementation-dependent but in theory, it's solid. I'm not sure what else a graph database would be able to do to beat an indexed adjacency list.
Comments
You can do recursive graph queries with PostgreSQL: http://www.postgresql.org/docs/9.5/static/queries-with.html
Agreed.
For shallow or narrow queries of the graph this is the way to go.
But for deep and broad queries, if you want to perform some valuable analysis that involves traversing the graph some non-trivial distance from the point of origin, that's where PostgreSQL is going to let you down and you would probably be better off picking a more appropriate tool.
Same question though: How do you want to query your graph, and are you willing to limit yourself to not querying it in a certain way?
I'm pretty sure you can get comparable performance from a graph in SQL if you make sure you have covering indexes for the Node ids and the edges/adjacency list table.
This may be implementation-dependent but in theory, it's solid. I'm not sure what else a graph database would be able to do to beat an indexed adjacency list.