51–60 of 80 posts
Earlier quoted context omitted.
Glad they used Cypher. One of the best and most intuitive query languages I've used personally.
I agree with you about Cypher. For a couple of decades I was a RDF and then RDF + SPARQL advocate, but I am a fairly recent convert to property graphs and Cypher.
There is also https://age.apache.org/ , an extension to facilitate graph queries in postgresql.
Glad they used Cypher. One of the best and most intuitive query languages I've used personally.
It’s a neat trick! A simpler choice would be to use Postgres’ own ltree data type: https://www.postgresql.org/docs/15/ltree.html I wrote about how we use it here: https://www.yetto.app/blog/post/how-labels-work/
That makes it good for relatively static and flat data like your label hierarchy, which probably receives a new label or a repainting within a tree relatively infrequently, and might have a p95 depth of 10. That makes it also a good fit for actual human (parent, child) relationships since parent-child change is usually infrequent and the total children per layer in the tree is also small.
For a tree like a Notion workspace where depth can be quite deep, and layers can easily have hundreds or hundreds of thousands of siblings, the cost at write-time when you reparent an ancestor in the worst case isn’t feasible.
For something like a social graph I’m not sure how to use ltree at all since a social graph isn’t a dag.
It is always good to know, at what point does "Postgres as X" break down. For instance, I know from experience that Postgres as timeseries DB (without add-ons) starts to break down in low billions of rows. It would be great to know that for graph DBs as well. I think a lot of people would prefer just to use Postgres if they can get away with it.
Im a big fan of GraphDatabase's since about 10 years. I even wrote my own "in memory graph storage" in golang for a specific use case that none of the big GraphDatabase's could cover at the time. That said - i WISH people would embrase the existing GraphDatabases more and make the hosters support them as standard, rather than abusing existing relational databases for graph purposes. And to make it clear,i'm not talki…
My personal opinion is that nobody should touch OrientDB with a 10 ft pole.
Earlier quoted context omitted.
Thats like saying why do we need json we can represent it also in a textfile but accessing values can be more tricky. Sure you can represent a GraphDB in a RDBMS - but graphdbs are optimized for their specific use case. Therefor for example locking of resources is optimized for said purpose. When going a "Edge" and "Node" table approach, locking is by default rather unoptimized in many RDBMS. Just one simple example.
> Thats like saying why do we need json we can represent it also in a textfile but accessing values can be more tricky. If your text processing stack works good enough, and JSON only solves edge cases, then I think its a legit argument against adding another tech to the stack. Its not like everyone immediately switched over to JSON even if they could have. And the analogy may not be the best - in the case of graph da…
My point was not about people enrichhing an existing RDMBS concept with Graph, it was about using RDBMS as Graph (as only purpose). So maybe i wasn't exact enaugh in my definition. Therefor:
"If your purpose is to use the benefits of Graph and you want to use it for this purpose only, use a GraphDB and dont use a RDBMS and make it a GraphDB."
I hope thats better now.
Im a big fan of GraphDatabase's since about 10 years. I even wrote my own "in memory graph storage" in golang for a specific use case that none of the big GraphDatabase's could cover at the time. That said - i WISH people would embrase the existing GraphDatabases more and make the hosters support them as standard, rather than abusing existing relational databases for graph purposes. And to make it clear,i'm not talki…
> rather than abusing existing relational databases for graph purposes. In my experience, the vast majority of graphs can be embedded in relational databases just fine and most people don't want general graph querying. People just don't like optimizing queries (or equivalently the schema to enable such queries). I personally have never seen a pitch for graph databases that makes them seem attractive for more than dat…
I don't think that GraphDBs should a default choice, but there are cases in which they just perform better.
Could i write my research project with a relational DB? Yes - i tried - and it sucked xD
It is always good to know, at what point does "Postgres as X" break down. For instance, I know from experience that Postgres as timeseries DB (without add-ons) starts to break down in low billions of rows. It would be great to know that for graph DBs as well. I think a lot of people would prefer just to use Postgres if they can get away with it.
I've been running into exactly that problem. Which time series add-on would you recommend looking into?
First-party data structure for tree (directed, acyclic graph) data