I've done this before with MySQL in 2011 after throwing my hands in the air with two different graph DBs.
By far the most productive thing I did. People will say that you need recursive queries, etc, but I found most of the time just keeping the query set in the application layer was easy enough and super fast. Scaling it was easier too because there are lots of articles on scaling the MySQL / Postgres.
Agreed, my reasons for coming back to Postgres are quite similar. In general, one only needs to go a few layers in the graph. Recursive queries are needed for specific use cases. Even then, querying from the app, like you said, and/or building materialized views and materialized paths are very good ways of working around this, as long as the query is anticipated in advance and the view/path built before the query. So that reduces the real use of graph db's to an even smaller subset - complex ad hoc graph queries.
Comments
I've done this before with MySQL in 2011 after throwing my hands in the air with two different graph DBs.
By far the most productive thing I did. People will say that you need recursive queries, etc, but I found most of the time just keeping the query set in the application layer was easy enough and super fast. Scaling it was easier too because there are lots of articles on scaling the MySQL / Postgres.
Agreed, my reasons for coming back to Postgres are quite similar. In general, one only needs to go a few layers in the graph. Recursive queries are needed for specific use cases. Even then, querying from the app, like you said, and/or building materialized views and materialized paths are very good ways of working around this, as long as the query is anticipated in advance and the view/path built before the query. So that reduces the real use of graph db's to an even smaller subset - complex ad hoc graph queries.