title: What is the difference between native graph storage and native graph processing?
body: <p>I thought by native graph storage you'd mean storing your data (on disk, not in memory) in adjacency lists/matrices, etc. (whatever serves your problem) instead of ways for example rdbms do. The part of graph processing for me was how that disk-saved data is represented in memory at runtime and how it is used to find answers for queries. As long as you have a similiar adjacency list-like structure in memory you gain index-free adjacency and your path traversals become a lot faster.</p>
  
  <p>After reading 'Graph Databases - New Opportunities for Connected Data' by Robinson, Webber and Eifrem I'm not so sure anymore. There also is <a href="http://i.stack.imgur.com/ieW0V.jpg" rel="nofollow">this</a> graphic that shows which graph databases offer which native or non-native functionalities. Why/When does it make sense to store graph data natively but to process it non-natively?</p>
  
  <p>So how would you explain the difference between native graph storage and native graph processing and at which level (of those two) does index-free adjacency come into play? Assuming a graph database always keeps the whole graph structure in memory (I think I've heard that neo4j is doing that), does it matter for querying performance (looking at index-free adjacency) whether a native or non-native graph storage is used? From my naive point of view I could imagine that the (de)serialization of the graph into/from memory can be done with a non-native, relational storage method, without losing too much performance. </p>