The previous answers have already done a good job of summarising the advantages and disadvantages of graph databases.
I would add one more advantage. The model in a graph database is easier to change than in a relational database. If the type of relationship in an RDBMS changes e.g. from 1:N to M:N I need to use DDL to change the model, which may require downtime. I don’t have this problem in a graph database where changing the relationships/edges between vertices is much easier.
I would add two disadvantages of a graph database over a relational database:
Graph databases are poor at aggregating data. Don’t use it for Business Intelligence.
It is difficult to implement versioning/auditing of data in a graph database. While not impossible it is rather awkward though.
I have written up a blog post on the pros and cons of graph databases in comparison to RDBMS. It also discusses the various use cases of a graph database and the different types of storage implementation:
https://sonra.io/2017/06/12/benefits-graph-databases-data-warehousing/