A lot of comments not sure about what Graph DBs are good for:<p>* Flexible knowledge association i.e. Knowledge Graphing<p>* Modeling and querying associations / models with many-steps-removed requirements<p>* Expert Systems / Inference Engines<p>* Lazy traversal for complex job scheduling<p>Graph DBs are not good at being a general purpose 95% of use cases database. Just use Postgres/MySQL if you're not sure. We use Neptune (AWS managed GraphDB) to model cybersecurity dependencies between many companies and report on supply chain vulnerabilities many steps removed. Those kinds of queries are non-trivial and expensive on anything but a Graph Database.<p>As GraphDBs meet niche query requirements you usually have other databases involved in the full application. If you want to tractably manage many databases in a system you ideally want to be in streaming / event sourced semantics. If you're already in an imperative crud-around-data / batch pipeline you'll find greater maintenance costs in adopting a GraphDB or any additional DB for that matter.
Graph databases have been the great white whale at my org for a number of years. We gave a crack at Janus a while back. It (like a few attempts at Neo4J) failed to deliver on the promise of unlocking queries with more than a hop or two, while dramatically underperforming on those one or two hop queries vs a graph implemented in MySQL.
There were a couple years where it was mostly abandoned. Good to see this solid graph database being well maintained. the milestones[1] mostly show a lot of upgrading libraries, some enhancements/features sprinkled in, but for a while Janus was nearly abandoned.<p>Maintenance re-started in 2017, with IBM & Google stepping up to back it[2].<p>[1] <a href="https://github.com/JanusGraph/janusgraph/milestones?state=closed" rel="nofollow">https://github.com/JanusGraph/janusgraph/milestones?state=cl...</a><p>[2] <a href="https://architecht.io/google-ibm-back-new-open-source-graph-database-project-janusgraph-1d74fb78db6b" rel="nofollow">https://architecht.io/google-ibm-back-new-open-source-graph-...</a>
Detailed read from two contributors on the project- <a href="https://www.ibm.com/cloud/blog/database-deep-dives-janusgraph" rel="nofollow">https://www.ibm.com/cloud/blog/database-deep-dives-janusgrap...</a>
To me, the downside of graph db is the non-standardized query language.<p>I tried Gremlin but it feels like an imperative DSL. Cypher queries are more readable, but are limited to Neo4J. I am looking forward for Open Cypher or maybe a variation of Facebook GraphQL.
Would it make sense to use a graph DB to model file hierarchies (folders and subfolders) at scale?<p>(hundreds of thousands of folders)<p>The idea would be to use a graph DB for a first query to get the file ids in scope (all files inside a given folder and its subfolders) before running the actual SQL query, eg creation_date < foo AND file_id in [array from graph db output]