4 ms·
If you use a graph database to store application data and you want a strict schema (and potentially improved performance), then YES. If you use a graph databas
by 1st1 5y ago
If you use a graph database to store application data and you want a strict schema (and potentially improved performance), then YES.
If you use a graph database to run graph algorithms on your data, then NO. Although we'll be working on adding support for recursive queries to EdgeQL in the near future.
- gazpacho 5y agoRight on. I have been in the position before where I needed to do some graph-like queries (where I had to traverse several levels of joins with the number of joins unknown a priori) but at the same time this was an application storing structured data. I found myself in a tight spot between doing some really clunky Postgres stuff or going the graph DB route. I would have loved to have something that can be used like a relational DB 95% of the time but can still handle that 5% of graph-like queries with reasonable performance and complexity.
- josefrichter 5y agomaybe have a look at arangodb, I think their value proposition is something like you wrote.
- gazpacho 5y agoindeed I remember looking at them. this was years ago, and I'm no longer on the project though :)
- gazpacho 5y agothis is still one of my favorite articles though: https://www.arangodb.com/learn/graphs/time-traveling-graph-databases/ https://www.arangodb.com/learn/graphs/time-traveling-graph-d...
- torgard 5y ago> Although we'll be working on adding support for recursive queries to EdgeQL in the near future. Is there a roadmap I can subscribe to somewhere? Looking forward to trying this out!