• I saw recently a paper comparing the performance of Postgres, MySql, Oracle and SQL Server.  As loads got more complex so the difference in performance between the proprietary and the open source became astounding.  That shouldn't surprise us.  The resources and time dedicated to the query engines of both Oracle & SQL Server are immense.  The problems that RDBMS' have had to solve remain intractably complex.
    That graph DBs, particularly distributed graphs like Titan/Aurelius are slower than expected should not surprise us for the same reason.  Oracle's approach to Graph DBs appears to be to implement graph algorithms over the top of an Oracle DB.
    Personally I have enjoyed playing with Neo4J.  I particularly like the Cypher query language.  It shares many syntax constructs with SQL while adding relatively straightforward graph extensions.  SQL Server 2017 seems to have recognised Cypher and implemented something with a high degree of similarity.
    I have no doubt that we could write SQL queries that produce the desired results that a graph database has been designed to produce. However such queries are non-trivial in SQL while straightforward in Cypher.  A graph database may satisfy the performance criteria while offering a simpler and more easily understood implementation.  RDBMS may offer performance far beyond the use case but require top notch SQL skills and associated cost to maintain and develop