[mumblemumble]

Well, first off: A graph database is typically considered a type of NoSQL database. Second off, a lot of graph databases use a SQL database such as PostgreSQL as the storage engine.

What really distinguishes graph databases is the querying language. There are a lot of these out there - RDF, Datalog, Cypher and Gremlin. These are typically optimized for modeling and making it easy to query against data with a high degree of interconnectedness. So, taking an RDBMS as the baseline, and assuming that by NoSQL you meant something like a column or document store that offers poorer support for ad-hoc queries than an SQL database, a graph database would be moving in the opposite direction.

Sort of. There's technically not anything a graph database can do that can't be expressed in modern (i.e., since the early 2000s for most, or 2018 if MySQL is your jam) SQL. But sometimes it can take a fair bit of effort to do so. If you find yourself frequently getting lost in a quagmire of complex joins and recursive CTEs, a graph DB can be a real boon for the maintainability of your data layer.

[rotten]

I'm not so sure that many graph databases use a relational database as the data store. Some use Linear Algebra representations of the graph. Some use key-value stores. Some are proprietary implementations that we'll never know exactly how the data is represented under the covers.

[rapnie]

RecallGraph at first glance looks a bit like TerminusDB that recently featured on HN [0]. In terminusdb data is stored like code in git, and you can time travel and do branch, merge, squash, rollback, diff, blame, etc. But TerminusDB is a semantic graph database based on OWL schemas, which stores data as RDF and querying delivers JSON-LD. I will certainly give RecallGraph a closer look.

[0] https://news.ycombinator.com/item?id=22867767

[patagurbon]

The only GraphBLAS(linear algebra) graph database is RedisGraph right?