Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Representing Graphs in PostgreSQL

richard-towers.com

Post reply on HN
Print view View original

31–40 of 80 posts

Re: Representing Graphs in PostgreSQL

#31

Post by hobs »

taurknaut wrote: post #21
voodooEntity wrote: post #8

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…

Yep, something like adjacency lists have solved a lot of dumb recursive queries/"graph queries" for me, usually because the graph doesn't change much and is just a few nodes deep.

Re: Representing Graphs in PostgreSQL

#32

Post by scotty79 »

osigurdson wrote: post #22

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.

any recursive query is absurdly slow, so I think it scales wonderfully only if you match your representation to your workload

Re: Representing Graphs in PostgreSQL

#33

Post by demaga »

osigurdson wrote: post #22

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 done almost exactly the kind of thing described in article for a couple millions of rows. It broke down when I needed to find "friends of friends" of depth 6. None of the optimizations I could come up with helped. Neither did Apache Age.

Maybe I'm just not skilled enough to handle such a workload with Postgres. But Neo4j handled it easily

Re: Representing Graphs in PostgreSQL

#34

Post by mark_l_watson »

CharlieDigital wrote: post #5
Epa095 wrote: post #2

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.

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.

Re: Representing Graphs in PostgreSQL

#36

Post by mark_l_watson »

manojlds wrote: post #7
CharlieDigital wrote: post #5

Earlier quoted context omitted.

Glad they used Cypher. One of the best and most intuitive query languages I've used personally.

Yeah Cypher was so good and made everything so intuitive. Loved working with Neo4J for a prototype and then had to face the licensing issues and huge costs and had to abandon it.

There are open source alternatives to Neo4J, and also very good scalable open source graph databases with query languages similar to Cypher. I think we are in agreement that it is a good idea to choose platform that scales both for compute and all other costs, like licensing costs.

Re: Representing Graphs in PostgreSQL

#37

Post by CharlieDigital »

mark_l_watson wrote: post #36
manojlds wrote: post #7

Earlier quoted context omitted.

Yeah Cypher was so good and made everything so intuitive. Loved working with Neo4J for a prototype and then had to face the licensing issues and huge costs and had to abandon it.

There are open source alternatives to Neo4J, and also very good scalable open source graph databases with query languages similar to Cypher. I think we are in agreement that it is a good idea to choose platform that scales both for compute and all other costs, like licensing costs.

Can you list them?

Not sure if you everyone reading is aware, but Neo4j did end up turning Cypher into the openCypher spec and that allowed a lot of other graph stores to adopt Cypher as a query language.

Re: Representing Graphs in PostgreSQL

#39

Post by mycall »

pella wrote: post #27

If you need some "Routing Graph" - check the pgRouting library https://pgrouting.org/ "pgRouting library contains following features: All Pairs Shortest Path, Johnson’s Algorithm All Pairs Shortest Path, Floyd-Warshall Algorithm Shortest Path A* Bi-directional Dijkstra Shortest Path Bi-directional A\* Shortest Path Shortest Path Dijkstra Driving Distance K-Shortest Path, Multiple Alternative Paths K-Dijkstra, One to…

Is it normally preferred to use some library such as this over a more traditional approach of nested sets, adjacency lists or ltree module?

Re: Representing Graphs in PostgreSQL

#40

Post by j45 »

osigurdson wrote: post #22

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 don’t think there’s a set predictable level of where Postgres as x can breakdown.

If you plan for it, for example store your graph in an export friendly format it should be ok.

Using postgres as long as you can get away with it is a no brainer. It’s had so many smart people working on it for so long it really comes thru. It’s nice to see the beginner or intro level tools for it evolving quickly similar to what has made MySQL approachable for so many years.

Post reply on HN