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.


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.

  • 1
    Thanks for your comment, Albert. I'm working on a project where the data model is very graph-like (lots of relationships among active record models), and using RDBMS has become painful in modeling it. Dec 11 '18 at 1:30
  • I know this is a really late response, but to add to the conversation. Dgraph Labs now supports a native spec compliant GraphQL endpoint. the main advantage of serving the GraphQL endpoint with a graph rather then serving it with a non graph, is that the graph solves the N+1 problem and eases the pressure of needing to join tables and documents. Just my opinion, but better yet, is the fact that with Slash GraphQL, you can spin up a complete backend graph database with a pure GraphQL endpoint in a single click. Layout your schema types and deploy. No more writing resolvers!
    – amaster
    Nov 6 '20 at 7:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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