I worked on a use case which was clearly in graph in nature. So graph database seemed a natural choice, of course Neo4j was one of the most heard product even back then.
We did evaluate Neo4j, but put down due to its complex query language (cypher) and slowness. It was really an awkward language, super awkward.
We also evaluated arangodb and we found it much better than Neo4j. Performance was good and its query language was better too.
What we realised in the process is, using graph databases is more of a cultural transformation as well. SQL is much well understood, well adopted and well supported by community.
Ultimately we implemented the use case in Postgres, and thank God we did it that way. IMO, we can still get all the benefits of graphs we SQL databases with little efforts.
We did evaluate Neo4j, but put down due to its complex query language (cypher) and slowness. It was really an awkward language, super awkward.
We also evaluated arangodb and we found it much better than Neo4j. Performance was good and its query language was better too.
What we realised in the process is, using graph databases is more of a cultural transformation as well. SQL is much well understood, well adopted and well supported by community.
Ultimately we implemented the use case in Postgres, and thank God we did it that way. IMO, we can still get all the benefits of graphs we SQL databases with little efforts.