<story><title>Postgres as a graph database</title><url>https://www.dylanpaulus.com/posts/postgres-is-a-graph-database/</url></story><parent_chain><item><author>mistermann</author><text>Piggybacking on your Neo4J reference....can anyone suggest any resources that would be good for someone from the SQL world who is very uninformed on graph databases to quickly get their head around the key ideas, but even more importantly, how to choose a platform among the offerings (licensing being I think a key issue, I&amp;#x27;ve heard Neo4J can get expensive)...assume a large, &amp;quot;social media&amp;quot; scale system, to be safe.</text></item><item><author>henryfjordan</author><text>I implemented pretty much exactly this setup once.&lt;p&gt;For what it&amp;#x27;s worth, there&amp;#x27;s a lot of footguns with this approach. You need to be careful about infinite cycles and things like that. You also just do not get the ergonomics of using a query language that is meant for graph data. Once you get it all setup and experience the issues you will no doubt be able to build whatever you want but there&amp;#x27;s a learning curve.&lt;p&gt;In the end we switched to using Neo4j and were able to build new features a lot more quickly than we would&amp;#x27;ve been able to on Postgres.&lt;p&gt;It&amp;#x27;s also worth mentioning that there are many ways to store graph data, and using an &amp;quot;adjacency list&amp;quot; like is being done here may or may not be the best way for your use case. Neo4j I think uses a different approach where nodes store info about edges they are connected to directly, so you don&amp;#x27;t even need to hit an index to follow an edge.</text></item></parent_chain><comment><author>henryfjordan</author><text>Neo4j has a self-hosted community edition that is free, though you need to update to Enterprise to expand your DB beyond one node. It&amp;#x27;s worth noting though that scaling from a single node to a cluster is going to have some pretty huge performance issues whether you are using SQL or Neo4j to store your graph. The power of graph databases is that it should be very inexpensive to follow an edge in the graph but when that leads to a network hop you lose a lot of performance.&lt;p&gt;If you are comfortable fitting your data onto one box, then development speed is probably more important than other factors and I would just try a few databases out and especially pay attention to how good the libraries are in your programming language of choice. Neo4j for instance had high quality libraries in Java but the experience in Python was not as good.&lt;p&gt;If you have a lot of data or need next-level performance, I would start by doing some research on the various ways to store graph data and then pick a DB that supports the approach you want to take.</text></comment>
<story><title>Postgres as a graph database</title><url>https://www.dylanpaulus.com/posts/postgres-is-a-graph-database/</url></story><parent_chain><item><author>mistermann</author><text>Piggybacking on your Neo4J reference....can anyone suggest any resources that would be good for someone from the SQL world who is very uninformed on graph databases to quickly get their head around the key ideas, but even more importantly, how to choose a platform among the offerings (licensing being I think a key issue, I&amp;#x27;ve heard Neo4J can get expensive)...assume a large, &amp;quot;social media&amp;quot; scale system, to be safe.</text></item><item><author>henryfjordan</author><text>I implemented pretty much exactly this setup once.&lt;p&gt;For what it&amp;#x27;s worth, there&amp;#x27;s a lot of footguns with this approach. You need to be careful about infinite cycles and things like that. You also just do not get the ergonomics of using a query language that is meant for graph data. Once you get it all setup and experience the issues you will no doubt be able to build whatever you want but there&amp;#x27;s a learning curve.&lt;p&gt;In the end we switched to using Neo4j and were able to build new features a lot more quickly than we would&amp;#x27;ve been able to on Postgres.&lt;p&gt;It&amp;#x27;s also worth mentioning that there are many ways to store graph data, and using an &amp;quot;adjacency list&amp;quot; like is being done here may or may not be the best way for your use case. Neo4j I think uses a different approach where nodes store info about edges they are connected to directly, so you don&amp;#x27;t even need to hit an index to follow an edge.</text></item></parent_chain><comment><author>joshspankit</author><text>As someone who hated being in the SQL world and couldn’t figure out why until years later when I found out about graph databases, here’s one big shift:&lt;p&gt;Graph database store true relationships.&lt;p&gt;The R in RDBMS and the concept of relationships by primary keys are lies (imo). They lead people away from what true relationships can be. Databases like Neo4j are not about doing any sort of PK or join or merge-before-query. Looking up by connection is the &lt;i&gt;fastest&lt;/i&gt; way to find information. If your RDBMS had one table for phone numbers, one for email addresses, one for first names, one for last names, one for street, and so-on it would take huge amounts of time to query to find all the detail for a single person. With a graph database it takes a small amount of time to find the first bit of info (let’s say phone number since it’s easily sorted), and then every other bit of linked data is essentially free.</text></comment>