Storing the data isn't an issue. It's fairly trivial to come up with a number of very good solutions to describing a graph.
The issue is querying the data, specifically when that involves walking the graph.
The real question then, is how do you want to query the data? If you are willing to make an assumption now that adds a tight constraint on your future work... i.e. "We will only ever perform queries that are at most 1 or 2 hops from the nodes/edges being queried" then perhaps PostgreSQL will work for you.
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.
You raise a good point. I don't expect graph queries that go more than a few links away. To the extent that there will be such queries, I think appropriate indexing will help a great deal.
Implementation wise, it is not that different from a query with many joins anyway - which is a standard problem, and is addressed by materialized views as well as indexing. So as long as the complex queries don't need to be ad hoc and real time, I can prepare for them using materialized views.
However you are quite right in that complex, ad hoc, and realtime graph queries Will be a pain point. That is a risk I am prepared to tolerate in the short term. The thing is, I also need transactional integrity, so I am stuck with an rdbms as the primary solution. In the long term, I anticipate the need for both graph queries and transactions - thus, I think it is better to start with postgres and incorporate a graphdb as the need arises than the other way round.
Hopefully this line of reasoning make sense? I am really not experienced at this, so am trying to not bump into too many walls.
Comments
Storing the data isn't an issue. It's fairly trivial to come up with a number of very good solutions to describing a graph.
The issue is querying the data, specifically when that involves walking the graph.
The real question then, is how do you want to query the data? If you are willing to make an assumption now that adds a tight constraint on your future work... i.e. "We will only ever perform queries that are at most 1 or 2 hops from the nodes/edges being queried" then perhaps PostgreSQL will work for you.
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.
You raise a good point. I don't expect graph queries that go more than a few links away. To the extent that there will be such queries, I think appropriate indexing will help a great deal.
Implementation wise, it is not that different from a query with many joins anyway - which is a standard problem, and is addressed by materialized views as well as indexing. So as long as the complex queries don't need to be ad hoc and real time, I can prepare for them using materialized views.
However you are quite right in that complex, ad hoc, and realtime graph queries Will be a pain point. That is a risk I am prepared to tolerate in the short term. The thing is, I also need transactional integrity, so I am stuck with an rdbms as the primary solution. In the long term, I anticipate the need for both graph queries and transactions - thus, I think it is better to start with postgres and incorporate a graphdb as the need arises than the other way round.
Hopefully this line of reasoning make sense? I am really not experienced at this, so am trying to not bump into too many walls.