How do graph databases differ from older navigational (hierarchical/network) databases?

Question

I'm trying to improve my knowledge of graph databases, in particular DGraph. Are graph DBMSs just a new generation of pre-relational hierarchical/network model DBMSs, or is there something new at a low level in the current generation of graph DBMSs (neo4j, etc.)? For example, the 60's-era CODASYL stored records in linked lists of free-form records. Isn't this just what current graph DB engines are doing?

My question isn't about things external to the fundamental way graph DBMSs function, like query language, replication, etc. I get that those areas have improved significantly.

Answer 1

Graph databases are largely irrelevant. What matters is the graph processing engines that use them. For that a dedicated graph database is not necessary: graphs can be represented in any sorts of stores: relational database, "nosql" databases (HBase, ...). Or even flat file structures. Some graph processing engines include their own dedicated graph store (that is the case for Neo4J and Graph). Others (Oracle Property Graph) let you use any storage you like.

In terms of processing capabilities, graph processing is very different from what was possible with the old Codasyl/Network databases. Graph processing lets you do graph analytics: finding influencers in social networks (page rank, closeness centrality, betweenness centrality ...), community detection, shortest paths, clustering ... They also let you traverse graphs using specialized languages such as PGQL or Cypher (for Neo4J). This is used to detect cycles: very useful for analyzing financial fraud and money laundering. Graph techniques have been used to analyze the Panama Papers for example. Same techniques are commonly used to analyze dependencies in complex processes, like car manufacturing or IT infrastructures. Note that work is under way to extend the SQL language with graph traversal expressions.

I don't know much about DGraph. A look at the documentation lets me believe that it does not provide any of the above: no graph analytics, and no actual graph traversal language. That may be because it actually implements graphs as RDF (semantic) graphs where data is abstracted as triples. RDF graphs can be constrained using ontologies that allow new triples to be inferred. RDF triple stores are generally queried using the SparQL language, but DGraph does not seem to support that either.

It would be interesting to know what sort of use case you have in mind that you think would be better solved by graph techniques, rather than relational techniques.