3 ms·
Right 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 jo
by gazpacho 5y ago
Right 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...