Talk:Graph database

This edit request by an editor with a conflict of interest has now been answered.

Please add the following entry to the list (see table below). The OpenCog AtomSpace is one of the early graph databases, dating back to 2005 or earlier. Its described in multiple books by Ben Goertzel, including "The Hidden Pattern", "The Structure of Intelligence", "Engineering General Intelligence", etc.

I think it's notable as having been one of the earliest graph databases that got heavily used in AI research; its got a pile of features and functions that none of the other listed databases have discovered yet (although its clear that some of these, e.g. Gremlin, is starting to move in that direction, as well as some of the newest google and amazon products are evolving in that direction as well. Thundering herd effect.) 67.198.37.16 (talk) 21:44, 23 December 2018 (UTC)

Reply 25-DEC-2018

   Clarification needed  

1. The required disclosure has not been made by the COI editor.
2. The proposal is unreferenced.^[a]

When ready to proceed with this information, please alter the {{request edit}} template's answer parameter to read from |ans=yes to |ans=no.
Regards,  Spintendo  23:50, 25 December 2018 (UTC)

Notes

1. [a]

   References for the proposed claim have not been formatted according to the citation style used by the article.

I'm not sure I get it. For the COI, it says to fill in the following template:

The following Wikipedia contributor has declared a personal or professional connection to the subject of this article. Relevant policies and guidelines may include conflict of interest, autobiography, and neutral point of view. [[User:User talk:67.198.37.16|User talk:67.198.37.16]] ([[User talk:User talk:67.198.37.16|talk]] · [[Special:Contribs/User talk:67.198.37.16|contribs]]) This user has declared a connection. (To the best of my recollection, I have never actually edited this particular article. I have made about 35 thousand edits to Wikipedia over the last 20 years. These are primarily on Mathematics and Physics; see User talk:67.198.37.16 for a list of articles I have made major contributions to. I have published journal articles and papers on many/most of the topics for which I edit Wikipedia. Sometimes I give public talks on these topics. A partial publication list can be found at, for example, https:///linas.org/math . The requested listing above is for the OpenCog AtomSpace, to which I am a primary contributor; see for example, https://github.com/opencog and also https://github.com/linas I have also worked at several corporations that have used the OpenCog AtomSpace in their products, including Northrup Grumman, Hanson Robotics, MOZI and Poulin Holdings. I have been involved with Huawei during their product evaluation of the AtomSpace. I count the inventor of the AtomSpace, Ben Goertzel, as a personal friend.)

References

1. [1]

   Goertzel, Ben (1993), The Structure of Intelligence, Springer-Verlag, doi:10.1007/978-1-4612-4336-6, ISBN 978-0-387-94004-5
2. [2]

   Goertzel, Ben (1993), The Evolving Mind, Gordon and Breach, doi:10.5860/choice.31-5976, ISBN 978-2881245879

The Properties section seems to be quite a jumble of disparate material. The "Storage" and "Index-free" subsections are about lower level details, whereas the "Graph types" subsection rather appears to be about what kind of information may be found in the database. And there is a strong business slant (as opposed to say science) in the choice of categories, so presumably the cited categorisation had a different scope than this article. 37.2.117.154 (talk) 09:10, 30 March 2023 (UTC)

Made "Graph types" subsection a section of its own, and renamed it. 130.243.94.123 (talk) 14:04, 13 April 2023 (UTC)

The example of searching for friends of Jack appears to be skewed to me. The graph database examples start by finding the person(s) named Jack and then finds friends of these, but the SQL example first builds a table of all pairs of friends, and only at the end filters out those where the first party isn't named Jack (even if query optimisation may change the order of operations). I think something like

 SELECT p2.person_name FROM 
  (SELECT * FROM people p1 WHERE p1.person_name = 'Jack')
  JOIN friend ON (p1.person_id = friend.person_id)
  JOIN people p2 ON (p2.person_id = friend.friend_id) 
 ;

might make a more fair comparison (but I'm not confident enough with my SQL that I trust I got the syntax right).

Also, a discussion in a general article such as this one should probably spell out how one even would store graph-like data in a relational database, before getting into pros and cons. Assuming triples, I suppose two approaches would be:

1. Make one big table with columns subject, predicate, object.
2. Make a separate table for each predicate, with columns subject, object.

The second approach would require changing the schema whenever adding a new predicate, which could be considered a big deal. The first suggests naive estimates for any basic operation would depend on total number of edges in the database (rather than, say, vertex degree), which is probably challenging. 37.2.117.154 (talk) 09:46, 30 March 2023 (UTC)

A long and detailed explanation for what you are asking about/looking for is given here: https://github.com/opencog/atomspace/raw/master/opencog/sheaf/docs/ram-cpu.pdf it goes into all the hows and whys of how this stuff works. 67.198.37.16 (talk) 04:16, 5 May 2024 (UTC)

The list of graph databases currently has a strong focus on these as software products — version, release date, licence, and implementation(?) languages all have separate columns — but there is no structured information about the capabilities of these systems! Two columns I'd like to suggest are:

• Graph model: The two main models appear to be property graph and RDF, but it is in many descriptions very difficult to tell which, if indeed any, of these two are supported. And then there is the possibility of minor variants, such as RDF versus RDF-star…
• Query API: A lot of the systems seem to promote their own solution here, but is that all they offer? It is probably useful if a system provides a SPARQL endpoint, even if its native model is not RDF. Some of the interfaces appear to be actual query languages (like SQL: not what you write your app in, but an actual separate language used for stating queries), whereas others are more APIs for building and using query objects.

130.243.94.123 (talk) 14:56, 13 April 2023 (UTC)

The OpenCog AtomSpace is about 20-25 years old, and is one of the first, if not the first graph database to hit the market (copyright notices give 2002 as the date) Sort of disappointed to not see it mentioned in the listing here. OpenSource: https://github.com/opencog/atomspace It transitioned from proprietary to open source in 2008. 67.198.37.16 (talk) 04:12, 5 May 2024 (UTC)

Location: "Compared with relational databases, graph databases are often faster for associative data sets and map more directly to the structure of object-oriented applications."

Source: Neo4j Official Documentation — “Transition from relational to graph database” page, published by Neo4j, a leading and pioneering graph database company founded in 2007, recognized globally as one of the primary innovators in graph technology. Neo4j’s database platform is widely adopted in industries such as finance, telecommunications, government, and technology, and it is frequently cited in both academic research and industry reports as a reference standard for graph database capabilities. The documentation notes that Neo4j can deliver orders of magnitude better performance for join-heavy queries by storing relationships as part of the data structure.

URL: https://neo4j.com/docs/getting-started/appendix/graphdb-concepts/graphdb-vs-rdbms/

Note: This reference should be added to Wikipedia as a citation source for the claim, providing authoritative support from Neo4j’s official documentation.

Location: “They can scale more naturally to large datasets as they do not typically need join operations, which can often be expensive.”

Source: Averbuch, A., & Neumann, T. — Partitioning Graph Databases – A Quantitative Evaluation (2013). Published on arXiv, an open-access scholarly repository maintained by Cornell University and widely used by the research community for disseminating peer-reviewed and preprint scientific papers. This academic paper explains that graph database systems link records by direct references, avoiding index lookups and enabling constant-time retrieval of adjacent elements regardless of graph size, whereas relational databases require index-based lookups and multiple table searches, which scale less efficiently.

URL: https://arxiv.org/abs/1301.5121

Location: “Despite the graph databases' advantages and recent popularity over relational databases, it is recommended the graph model itself should not be the sole reason to replace an existing relational database.”

Source: A 2025 article by InterSystems titled “Graph Database vs Relational Database: Which Is Best for Your Needs?” — published by InterSystems, a globally recognized database and data management technology provider founded in 1978, whose products power mission-critical systems in healthcare, finance, logistics, and government sectors. This technical resource highlights that graph databases offer flexibility and adaptability, yet for many enterprise scenarios—especially those requiring ACID transactions and structured transactional workloads—the strengths of relational databases remain compelling, emphasizing that transitioning solely based on the graph model isn't always justified.

URL: https://www.intersystems.com/resources/graph-database-vs-relational-database-which-is-best-for-your-needs/

Location: "Second-generation distributed graph database with the flexibility of documents in one product (i.e., it is both a graph database and a document NoSQL database)."

Source: OrientDB Official Documentation — Overview page, maintained by the OrientDB development team and recognized as the authoritative primary source for technical and architectural information about OrientDB. It declares that OrientDB is “the first Multi-Model Open Source NoSQL DBMS that combines the power of graphs and the flexibility of documents into one scalable, high-performance operational database.”

URL: https://orientdb.dev/docs/3.0.x/misc/Overview.html Jaroslav Radomír (talk) 05:53, 13 August 2025 (UTC)