Pith. sign in

REVIEW 1 major objections 6 minor 27 references

NoSQL Graph Databases: an overview

T0 review · 1 major / 6 minor · reviewed 2026-08-11 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read This survey compares Neo4j and AllegroGraph in depth, and argues that their differences trace to a single choice of graph model: the labeled property graph versus RDF triples.

desk verdict A useful survey that contradicts itself on AllegroGraph's storage in the very table it tells readers to use for decisions; otherwise a careful, honest overview. read the letter →

arxiv 2412.18143 v1 pith:AXYM3DVU submitted 2024-12-24 cs.DB cs.SC

Veronica Santos , Bruno Cuconato This is my paper · ORCID
classification cs.DBcs.SC
keywords NoSQLgraphdatabasesNeo4jAllegrolabeledpropertyRDFCypherSPARQL
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper is a survey of NoSQL graph databases that focuses on the two most common graph models in practice: the labeled property graph (LPG) and the RDF triple model. It argues that these models, more than any single feature, determine how a graph store is built, queried, and traded off against consistency and scalability. The paper's central contribution is a detailed comparison of Neo4j, the leading LPG store, and AllegroGraph, a leading RDF triple store, across storage, query language, consistency, isolation, sharding, and backup. If the comparison is accurate, it gives practitioners a grounded way to choose between the two systems, and it highlights where prior surveys got the details wrong.

What carries the argument

The paper's central objects are the two graph data models it compares: the labeled property graph (LPG), a tuple of vertices, edges, labels, and key-value properties, and RDF, a set of subject-predicate-object triples over URIs, blank nodes, and literals. Around these models the paper organizes the machinery that separates the two systems: Neo4j's native storage with fixed-size records and index-free adjacency (direct pointers between adjacent nodes, so node lookup is constant-time without an index) versus AllegroGraph's non-native triple storage with seven automatically built indexes (spogi, posgi, ospgi, gspoi, gposi, gospi, and i). The two query languages—Cypher, a declarative, clause-based, ASCII-art-inspired language for the LPG, and SPARQL 1.1, the W3C-standard pattern-matching language for RDF—carry the comparison of query capabilities; consistency and isolation guarantees are then described with the standard machinery of CAP, linearizability, read committed, snapshot isolation, and the Raft protocol for Neo4j's clusters.

What would settle it

Run the same connected-data workload (for example, k-neighborhood and shortest-path queries) on the same graph modeled as a property graph in Neo4j and as RDF triples in AllegroGraph, on comparable hardware; if traversal latency on AllegroGraph is not consistently higher in the index-based setting, the paper's claim about non-native triple storage limiting traversal efficiency is undercut. Alternatively, inspect a current Neo4j release: if nodes no longer store direct pointers to adjacent nodes, the described storage model no longer holds.

Watch

Extended reading notes

Core claim

The paper's claim is that NoSQL graph databases are best understood through their data models, and that the LPG/RDF divide explains the most consequential engineering differences between systems. Neo4j stores nodes and relationships as fixed-size records with direct pointers (index-free adjacency), giving constant-time node lookup and constant-time insertion, at the cost of linear-time neighbor checks; AllegroGraph stores RDF triples/quads in non-native, index-based storage, which aids horizontal scaling but makes relationship traversal more expensive. These architectural differences translate into different query languages (Cypher's pattern matching and path navigation versus SPARQL's pattern matching), different consistency profiles (Neo4j offers causal consistency in clusters via bookmarks, degrading to eventual consistency without them; AllegroGraph provides strong consistency and snapshot isolation without write concurrency), and different CAP classifications (Neo4j as AP, AllegroGraph as CP). The paper corrects prior surveys that mislabeled Neo4j's query language and AllegroGraph's consistency, and it consolidates its findings in a comparison table intended as a decision reference.

Load-bearing premise

The survey's descriptions of Neo4j and AllegroGraph come from vendor documentation and earlier published surveys rather than from independent experiments or benchmarks, so the accuracy of its comparison table depends on those sources being current and correct.

Editorial extensions

If this is right

  • If the LPG/RDF divide is the right lens, a practitioner's first decision in choosing a graph store is which model fits the data, not which product has a longer feature list.
  • Neo4j's constant-time node lookup and insertion suit OLTP-style connected-data workloads, while AllegroGraph's index-based triple storage better matches analytics scenarios where traversal latency is a secondary concern.
  • The comparison table can serve as a decision aid: choose AllegroGraph when strong consistency, W3C standardization, federated SPARQL, and automatic sharding matter; choose Neo4j when native traversal, graph-native querying, and causal consistency with bookmarks matter.
  • Prior surveys that classified Neo4j as a SPARQL/Gremlin user or AllegroGraph as AP are incorrect, so decisions or benchmarks built on those surveys need revisiting.
  • Because the field is fast-evolving, the paper's table is a snapshot that should be re-verified against current vendor documentation before use.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The paper's criterion for native processing (index-free adjacency) could be applied to other triple stores and graph databases to produce a more objective taxonomy than vendor labels alone.
  • The AP/CP classification suggests a concrete test: run a bookmark-less Neo4j cluster and an AllegroGraph cluster under a partition and observe whether convergence behavior matches the paper's consistency claims.
  • The comparison could be extended with a benchmark that takes the same graph expressed both as an LPG and as RDF triples, then measures traversal latency on each store to test the claim that triple stores are less efficient at relationship traversal.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

1 major / 6 minor

Summary. This manuscript is a survey of NoSQL graph databases. It introduces graph models (LPG and RDF), storage and query-language dimensions, and then analyzes two systems in depth: Neo4j (labeled property graph) and AllegroGraph (RDF). It also reviews earlier surveys, explicitly corrects what it identifies as outdated or erroneous statements in them, and includes a short appendix of SPARQL snippets from small AllegroGraph tests. The stated contribution is an accurate description of how graph databases differ and a comparison table that can serve as a reference for choosing between the two systems.

Significance. If its factual claims are reliable, this is a clearly structured and potentially useful overview, particularly because it corrects prior surveys and grounds its AllegroGraph discussion in hands-on SPARQL examples. The comparison table is the central deliverable, and the paper is candid about the fast-evolving nature of the field. However, the value of that central deliverable is currently weakened by an internal inconsistency in the native/non-native classification of AllegroGraph, and most factual content is drawn from vendor documentation without independent verification.

major comments (1)
  1. [Table 1 vs. §4.6] Table 1 classifies AllegroGraph's graph storage as 'Native', but §4.6 explicitly states: 'The storage is non-native, that is, edges aren't stored in the adjacency list format.' Under the paper's own §2.2 taxonomy, native storage uses graph-aware logical models while non-native storage relies on non-graph data organizations, so the table and the text cannot both be correct. Since the conclusion presents Table 1 as 'a reference for deciding on which system is better for a given use-case,' this contradiction directly undermines the paper's central contribution. The authors should correct either the table or the text and apply the native/non-native distinction consistently across §2.2, §4.6, and Table 1.
minor comments (6)
  1. [§2.1] The definition of a simple graph reads 'E ⊆ E × E'; it should be 'E ⊆ V × V'. This typo makes the formal definition circular and should be fixed.
  2. [§2.3] The statement that Cypher 'has been standardized as openCypher' is imprecise; openCypher is a community specification rather than a formal standard, which conflicts with the earlier use of 'standardized' to mean by a major institution such as ISO, ANSI, W3C, ECMA, or the IETF.
  3. [§4.4] Figure 6 caption says 'Transactions from two database clients', but the figure and surrounding text refer to three clients (C1, C2, C3). The caption should be aligned with the example.
  4. [§4.6] There are several grammatical slips that should be corrected, for example 'There is two ways to supports datatypes' and 'AllegroGraph currently do supports basic graph path queries'.
  5. [§4.2] Footnote 17 states that the on-disk storage description is for Neo4j version 2, while the rest of the paper discusses version 4. Either a v4 reference should be added or the version limitation should be made more prominent in the main text.
  6. [§1 / Abstract] The Portuguese abstract (Resumo) and keywords (Palavras-chave) are left as placeholders; these should be completed or removed before publication.

Circularity Check

0 steps flagged · score 0.0 of 10

No circular reasoning: the paper is a descriptive survey that compiles and compares external sources; its claims do not reduce to its own inputs.

full rationale

This paper is a survey and comparison of Neo4j and AllegroGraph. It does not present a formal derivation, prediction, or fitted model. The descriptions of the two systems are drawn from external references, vendor documentation, and the authors' own SPARQL tests in the appendix. There are no self-citations, no imported uniqueness theorems, and no parameters fitted to data that are later renamed as predictions. The central claim is that the overview and comparison table are accurate, which is an empirical adequacy claim about external systems, not a claim derived from its own assumptions. A separate internal inconsistency exists: Table 1 lists AllegroGraph's graph storage as 'Native' while Section 4.6 states 'The storage is non-native,' and this is a factual contradiction that affects the paper's usefulness as a decision reference. However, a contradiction is a correctness concern, not a circularity concern: the paper does not use that claim to prove itself. Under the stated circularity criteria, no step reduces by construction to the paper's own definitions, fitted values, or self-citations, so the appropriate score is 0.

Assumptions & free parameters 0 free parameters · 3 assumptions · 0 invented entities

The survey introduces no free parameters or invented entities. It relies on standard database concepts (CAP, ACID, graph models) and on vendor documentation as domain assumptions.

assumptions (3)
  • domain assumption The CAP theorem is a valid framework for classifying distributed databases.
    Used in Sections 2.5 and 4.6 to classify AllegroGraph as CP and Neo4j as AP/causal.
  • standard math The definitions of LPG and RDF models are taken as given from prior literature (Angles and Gutierrez; W3C).
    Section 2.1 adopts these definitions to compare the two systems.
  • ad hoc to paper Vendor documentation for Neo4j and AllegroGraph accurately describes system behavior.
    The survey's factual claims about features, isolation levels, and storage layout rely on official manuals rather than independent tests.

how reviews work

0 comments
Cite this review

Pith. "Pith review of NoSQL Graph Databases: an overview." pith.science (2026). https://pith.science/paper/AXYM3DVU

@misc{pith2026241218143,
  author       = {Pith},
  title        = {Pith review of: NoSQL Graph Databases: an overview},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/AXYM3DVU}},
  note         = {Machine review of arXiv:2412.18143}
}
read the original abstract

Graphs are the most suitable structures for modeling objects and interactions in applications where component inter-connectivity is a key feature. There has been increased interest in graphs to represent domains such as social networks, web site link structures, and biology. Graph stores recently rose to prominence along the NoSQL movement. In this work we will focus on NOSQL graph databases, describing their peculiarities that sets them apart from other data storage and management solutions, and how they differ among themselves. We will also analyze in-depth two different graph database management systems - AllegroGraph and Neo4j that uses the most popular graph models used by NoSQL stores in practice: the resource description framework (RDF) and the labeled property graph (LPG), respectively.

Figures

Figures reproduced from arXiv: 2412.18143 by the authors.

Figure 1
Figure 1. The Graph Database Space G where V ′ = Student, x and E′ = (Student, x), and Student is the identifier of the student in question and x is a variable. The query engine then finds all subgraphs that match the subgraph specified by the query. The process of receiving a query and returning its matching results is known as query eval￾uation. This definition of evaluation as finding matching subgraphs is informal, since … view at source ↗
Figure 2
Figure 2. Binary structure of node and relationship store files in Neo4j versions 2.* [8] [PITH_FULL_IMAGE:figures/full_fig_p014_2.png] view at source ↗
Figure 3
Figure 3. Graph representation in Neo4j [8] Letting node and relationship identifiers be mere indices of their respective records allows us constant time access to them. As an example, if a node references a relationship with ID 3, we know it is the third record on the relationship store file. Because records in this file have a fixed size, we can compute the byte offset to where the record starts and thus access it in consta… view at source ↗
Figures from the paper (8 more)
Figure 4
Figure 4. Figure 4: Cypher query returning the classes a student attends [PITH_FULL_IMAGE:figures/full_fig_p015_4.png]
Figure 5
Figure 5. Figure 5: Typical Neo4j cluster architecture [24, §7.1] C1: R: x=x0 W: x=x1 C2: R: x=x1 W: y=y1 C3: R: y=y1 R: x=x0 [PITH_FULL_IMAGE:figures/full_fig_p016_5.png]
Figure 7
Figure 7. Figure 7: Schema for schedules that perform dirty writes [PITH_FULL_IMAGE:figures/full_fig_p017_7.png]
Figure 9
Figure 9. Figure 9: Schema for schedules that perform dirty reads [PITH_FULL_IMAGE:figures/full_fig_p017_9.png]
Figure 10
Figure 10. Figure 10: Example schedule were a dirty read is performed [PITH_FULL_IMAGE:figures/full_fig_p018_10.png]
Figure 11
Figure 11. Figure 11: AllegroGraph sharding the documentation the replication solution is a real-time transactionally consistent data replica￾tion solution. Distributed systems has to sacrifice some availability in order to provide strong consistency, i. e., to guarantee data consistency a…
Figure 12
Figure 12. Figure 12: AllegroGraph Components recated or re-branded.21 There is still no clearly predominant query language for graph databases like SQL is relational databases, although the language being considered for standardization by ISO (see section 2.3) might come to fulfill this r…
Figure 13
Figure 13. Figure 13: Graph data example used in AllegroGraph tests [PITH_FULL_IMAGE:figures/full_fig_p026_13.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

27 extracted references · 25 canonical work pages

  1. [1]

    LIU, M..A survey on nosql stores

    DAVOUDIAN, A.; CHEN, L. ; LIU, M..A survey on nosql stores. ACM Computing Surveys (CSUR), 51(2):1–43, 2018

    work page 2018

  2. [2]

    Survey of graph database models

    ANGLES, R.; GUTIERREZ, C.. Survey of graph database models . ACM Computing Surveys (CSUR), 40(1):1–39, 2008

    work page 2008

  3. [3]

    WILKINS, D

    VICKNAIR, C.; MACIAS, M.; ZHAO, Z.; NAN, X.; CHEN, Y. ; WILKINS, D.. A comparison of a graph database and a relational database: A data provenance perspective . In: PROCEEDINGS OF THE 48TH ANNUAL SOUTHEAST REGIONAL CONFERENCE, ACM SE ’10, New York, NY, USA, 2010. Association for Computing Machinery

    work page 2010

  4. [4]

    HOEFLER, T

    BESTA, M.; PETER, E.; GERSTENBERGER, R.; FISCHER, M.; PODSTAWSKI, M.; BARTHELS, C.; ALONSO, G. ; HOEFLER, T.. Demystifying graph databases: Analy- sis and taxonomy of data organization, system designs, and graph queries . arXiv preprint arXiv:1910.09017, 2019. 21

    arXiv 1910

  5. [5]

    VRGO ˇC, D

    ANGLES, R.; ARENAS, M.; BARCEL ´O, P.; HOGAN, A.; REUTTER, J. ; VRGO ˇC, D.. Foun- dations of modern query languages for graph databases . ACM Computing Surveys (CSUR), 50(5):1–40, 2017

    work page 2017

  6. [6]

    DAS, S.; SRINIVASAN, J.; PERRY, M.; CHONG, E. I. ; BANERJEE, J.. A tale of two graphs: Property graphs as rdf in oracle . In: EDBT, 2014

    work page 2014

  7. [7]

    GROUP, O. I.. Cypher Query Language Reference Version 9 . See also https: //www.opencypher.org/resources, https://web.archive.org/ web/20181115192608/https://s3.amazonaws.com/artifacts. opencypher.org/openCypher9.pdf (Accessed: 2020-06-18)

    work page arXiv 2020

  8. [8]

    EIFREM, E

    ROBINSON, I.; WEBBER, J. ; EIFREM, E.. Graph databases: new opportunities for connected data. O’Reilly Media Inc., 2015

    work page 2015

Show all 27 references
  1. [9]

    EIFREM, E

    ROBINSON, I.; WEBBER, J. ; EIFREM, E.. Graph Databases: New Opportunities for Connected Data. O’Reilly Media, Inc., 2nd edition, 2015

    2015

  2. [10]

    Fundamentals of database systems

    ELMASRI, R.; NAVATHE, S.. Fundamentals of database systems . Pearson, 7 edition, 2016

    2016

  3. [11]

    Consistency in non-transactional distributed storage sys- tems

    VIOTTI, P.; VUKOLI ´C, M.. Consistency in non-transactional distributed storage sys- tems. ACM Comput. Surv., 49(1), June 2016

    2016

  4. [12]

    BERNARDINO, J

    DIOGO, M.; CABRAL, B. ; BERNARDINO, J.. Consistency models of nosql databases . Future Internet, 11(2):43, 2019

    2019

  5. [13]

    O’NEIL, P..A critique of ANSI SQL isolation levels

    BERENSON, H.; BERNSTEIN, P.; GRAY, J.; MELTON, J.; O’NEIL, E. ; O’NEIL, P..A critique of ANSI SQL isolation levels . ACM SIGMOD Record, 24(2):1–10, 1995

    1995

  6. [14]

    CLEMENT, A

    CROOKS, N.; PU, Y.; ALVISI, L. ; CLEMENT, A.. Seeing is believing: A client-centric specification of database isolation. In: PROCEEDINGS OF THE ACM SYMPOSIUM ON PRINCIPLES OF DISTRIBUTED COMPUTING, p. 73–82, 2017

    2017

  7. [15]

    Graph databases comparison: AllegroGraph, ArangoDB, InfiniteGraph, Neo4J, and OrientDB

    FERNANDES, D.; BERNARDINO, J.. Graph databases comparison: AllegroGraph, ArangoDB, InfiniteGraph, Neo4J, and OrientDB . p. 373–380, 01 2018

    2018

  8. [16]

    SCHIAFFINO, S..Persisting big data: The nosql landscape

    CORBELLINI, A.; MATEOS, C.; ZUNINO, A.; GODOY, D. ; SCHIAFFINO, S..Persisting big data: The nosql landscape . Information Systems, 63:1–23, 07 2017

    2017

  9. [17]

    RITTER, N

    GESSERT, F.; WINGERATH, W.; FRIEDRICH, S. ; RITTER, N.. Nosql database systems: A survey and decision guidance . Comput. Sci., 32(3–4):353–365, July 2017

    2017

  10. [18]

    A comparison of current graph database models

    ANGLES, R.. A comparison of current graph database models . p. 171–177, 04 2012

    2012

  11. [19]

    PRAT, N..A four v’s design approach of nosql graph databases

    AKOKA, J.; COMYN-WATTIAU, I. ; PRAT, N..A four v’s design approach of nosql graph databases. In: de Cesare, S.; Frank, U., editors, ADVANCES IN CONCEPTUAL MODELING, p. 58–68, Cham, 2017. Springer International Publishing

    2017

  12. [20]

    Graph databases: A survey

    KUMAR KALIYAR, R.. Graph databases: A survey. In: INTERNATIONAL CONFERENCE ON COMPUTING, COMMUNICATION AUTOMATION, p. 785–790, 2015. 22

    2015

  13. [21]

    Neo4j high performance

    RAJ, S.. Neo4j high performance. Packt Publishing Ltd, 2015

    2015

  14. [22]

    TAYLOR, A

    FRANCIS, N.; GREEN, A.; GUAGLIARDO, P.; LIBKIN, L.; LINDAAKER, T.; MARSAULT, V.; PLANTIKOW, S.; RYDBERG, M.; SELMER, P. ; TAYLOR, A.. Cypher: An evolving query language for property graphs . In: PROCEEDINGS OF THE 2018 INTERNATIONAL CONFERENCE ON MANAGEMENT OF DATA, p. 1433–1445, 2018

    2018

  15. [23]

    APOC — Awesome procedures on Cypher for neo4j

    CONTRIBUTORS, A.. APOC — Awesome procedures on Cypher for neo4j . website. https://web.archive.org/web/20200520200352/https:// neo4j.com/docs/labs/apoc/current/

  16. [24]

    The Neo4j operations manual v4.0, 2020

    Neo4j Inc. The Neo4j operations manual v4.0, 2020. https://neo4j.com/docs/ operations-manual/4.0/ (Accessed: 2020-06-20)

    2020

  17. [25]

    In search of an understandable consensus algorithm

    ONGARO, D.; OUSTERHOUT, J.. In search of an understandable consensus algorithm. In: 2014 {USENIX} ANNUAL TECHNICAL CONFERENCE ({USENIX}{ATC} 14), p. 305– 319, 2014

    2014

  18. [26]

    The Neo4j drivers manual v4.0 , 2020

    Neo4j Inc. The Neo4j drivers manual v4.0 , 2020. https://neo4j.com/docs/ driver-manual/4.0/ (Accessed: 2020-06-22)

    2020

  19. [27]

    The Neo4j Java Developer Reference v4.0, 2020

    Neo4j Inc. The Neo4j Java Developer Reference v4.0, 2020. https://neo4j.com/ docs/java-reference/4.0 (Accessed: 2020-06-18). 23 Figure 13: Graph data example used in AllegroGraph tests A AllegroGraph tests in SPARQL This appendix contains SPARQL commands used to manipulate (cr...

    2020

Pith tools

Reviewed August 11, 2026 · model on record in the stance chip above.