Pith. sign in

REVIEW 3 major objections 6 minor 55 references

Graph Neural Networks on Graph Databases

T0 review · 3 major / 6 minor · reviewed 2026-08-12 · deepseek-v4-flash

Pith's one-line read A graph neural network can be trained by letting the graph database do neighbour sampling and feature retrieval, so the graph never has to be loaded into memory.

desk verdict A genuinely new systems idea for GNN training via graph-DB queries, but the headline memory claim is undercut by the Neo4j configuration in the paper's own appendix. read the letter →

arxiv 2411.11375 v1 pith:2HUGA36R submitted 2024-11-18 cs.LG cs.DB

classification cs.LGcs.DB
keywords graphneuralnetworksdatabasesneighbourhoodsamplingCypherqueriesmemory-efficienttrainingSAGEdistributedpartitioning
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

Training a graph neural network usually begins by loading the whole graph into memory, which caps model size by RAM. This paper tries to remove that cap: it proposes expressing neighbour sampling and feature retrieval as graph-database queries, so the training process materialises only the sampled batch of nodes and features. If the approach is right, GNN training becomes possible on machines with far less memory than the graph, and graph databases take on the role of graph store, feature store, and sampler in one. The authors support this with experiments on two large benchmarks, including successful training on a machine with 8 GB of RAM and roughly linear speedup in distributed training up to CPU saturation.

What carries the argument

The central mechanism is a graph-query template: given a batch of seed nodes, it performs a multi-hop pattern match, applies ORDER BY rand() followed by LIMIT $MAX_NEIGHBOURS to cap only the final sampled neighbourhood, and returns sampled node IDs together with their features in a single round-trip. The paper adapts standard GNN library interfaces so the database supplies both graph structure and features, replacing the usual in-memory graph representation and separate feature store. Limiting only the final hop, rather than each hop, is the optimisation that keeps intermediate materialisation small; it changes the sampling distribution relative to GraphSAGE's per-layer node-wise sampling, and the paper checks only the empirical degree distribution of sampled nodes as validation.

What would settle it

Run the same GraphSAGE model, with identical hyperparameters and seeds, on ogbn-products using the paper's database sampler and using the standard in-memory per-layer sampler; if test accuracy differs by more than run-to-run noise, the final-hop-only random LIMIT has changed the model and the claim that database queries reproduce GraphSAGE sampling fails.

Watch

Extended reading notes

Core claim

The claim, stated in the authors' own terms, is that the data-access steps of mini-batch GNN training — initial metadata loading, multi-hop neighbour sampling, and feature retrieval — can be offloaded to a graph database, leaving only the minimal per-batch data in memory. The paper implements this with a query template that chains two-hop pattern matches, orders the result by a random value, and applies LIMIT to cap the final neighbourhood, while fetching node features in the same query. Empirically the setup trains GraphSAGE on ogbn-papers100M with 8 GB of RAM and under 1 KB of RAM at initialisation instead of 48 GB, and scales across multiple training processes reading from one database. The authors present this as a new way to scale GNNs and a new workload for graph databases.

Load-bearing premise

The approach assumes that a database drawing a random cap of final-hop neighbours produces the same kind of neighbourhood sample as GraphSAGE's per-layer sampling, so that the model learned is the one the paper claims to train.

Editorial extensions

If this is right

  • GNN training becomes possible on machines whose RAM is far smaller than the graph, because memory use is bounded by the sampled neighbourhood of one batch plus model weights rather than by the full graph.
  • The separate graph-partitioning step for distributed training can be replaced by the database's horizontal scaling and concurrent read support, removing a preprocessing cost and a reproducibility concern.
  • Feature storage can live with the graph in the same database, eliminating a separate feature store and the consistency maintenance between stores.
  • Training throughput scales smoothly with hardware: more RAM or more processes reduces per-epoch time until the CPUs are saturated, as observed with eight processes in the distributed setup.
  • Graph databases gain a concrete machine-learning workload, since sampling-as-a-query is a read pattern distinct from traditional transactional and analytical database workloads.

Reading between the lines

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

  • The paper validates the sampler only by the shape of the degree distribution, not by comparing model accuracy against the standard GraphSAGE sampler; the strongest version of the claim would require an accuracy-parity test.
  • Because the random cap applies only to the final hop, the joint distribution over sampled multi-hop neighbourhoods differs from per-layer node-wise sampling, which could matter on graphs with highly skewed degrees.
  • A natural extension is to push the mean aggregation of the GraphSAGE update into the query engine as well, since mean is a basic aggregation operator in graph databases and the paper notes this direction.
  • The same query formulation could make single-node inference cheap, because classifying a new node would require only a local neighbourhood query rather than reconstructing the full graph.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

3 major / 6 minor

Summary. The paper proposes training GNNs by offloading neighbourhood sampling and feature retrieval to a graph database query engine, so that only minimal metadata and per-batch query results are materialized in the training process. The method is implemented with PyG and Neo4j, and evaluated on ogbn-papers100M and ogbn-products in single-machine and distributed settings. The main reported results are that single-machine training can proceed with as little as 8 GB RAM for ogbn-papers100M, and that distributed training scales roughly linearly up to 8 processes while keeping the database as a central store. The paper also includes a query-plan analysis and an empirical degree-distribution check for the sampling query.

Significance. If the memory-scaling claim is valid, the paper opens a practical new direction for training GNNs on graphs that do not fit in RAM, and it builds a bridge between graph database systems and graph ML. The work is accompanied by released code, a query-plan verification in Section 5.1, and distributed experiments that go beyond a simple feasibility study. However, the significance is currently constrained by the unresolved memory accounting and by the lack of a model-accuracy baseline, both of which are central to the paper's claims.

major comments (3)
  1. [Section 5.2 / Table 2 / Appendix C] The headline claim that training ogbn-papers100M is possible on a machine with 8 GB RAM is not established, because the memory column appears to exclude the graph database server. Appendix C states that Neo4j is configured with dbms.memory.heap.initial_size = 32GB, dbms.memory.heap.max_size = 32GB, and dbms.memory.pagecache.size = 32GB. If Neo4j runs on the same machine as the training process, the 8 GB figure is incompatible with a 32 GB JVM heap plus a 32 GB page cache; if Neo4j runs on a separate server, the experiment is not single-machine and the database node's memory is omitted from the RAM column. The paper must either report actual end-to-end peak memory for the whole system or clearly state that the RAM column refers only to the training process, not the database server.
  2. [Section 4 / Figure 4 / Equation (2)] The sampling query in Figure 4 applies ORDER BY rand() LIMIT $MAX_NEIGHBOURS to the combined result set across all seed nodes, which is not the per-node, per-layer uniform sampling defined by GraphSAGE in Equation (2). This changes the number of neighbours per seed node and the layer-wise sampling semantics, since the global limit may exhaust the budget on a few high-degree seeds and leave others with fewer or no sampled neighbours. The paper acknowledges this optimization in Section 4 but validates it only with the marginal degree-distribution check in Appendix D, which does not test per-seed coverage or downstream model behaviour. To support the claim that the method trains the stated model, the authors should compare the sampling distribution (or, more directly, model accuracy) against the standard per-node GraphSAGE sampler, or explicitly reframe the method as training a different, database-sampled model.
  3. [Section 5.3] The reported accuracy of 58% after 10 epochs is not compared against any baseline, so it cannot support the claim that the proposed pipeline trains a functioning GraphSAGE model. The text says 'our model gives an average of 58% accuracy' but gives no standard GraphSAGE accuracy on the same task, data split, and hyperparameters, and no indication of whether 58% is typical for this dataset after 10 epochs with the same architecture. Without such a comparison, the reader cannot distinguish between a correct implementation with expected accuracy and a pipeline whose sampling or feature retrieval corrupts the training signal.
minor comments (6)
  1. [Section 2.1 / Equation (1)] There are small notation errors in Equation (1): the initial condition refers to 'x(0)_v in R^{1*n} for u in V' and the neighbourhood is described as 'some neighbourhood of u', where the intended variable is v. Please correct these.
  2. [Section 5.2] The statement that the approach 'should enable graph ML workloads for extremely large graphs, such as Graph500-scale34' is speculative and not supported by any experiment in the paper. It should be marked as future work or removed.
  3. [Appendix D] The empirical sampling-distribution check is performed on ogbn-products, not on ogbn-papers100M, and it reports only the marginal frequency of sampled nodes. It would be more informative to also report per-seed neighbourhood sizes and compare them with the intended per-node limit, especially since the global LIMIT is the main source of divergence from GraphSAGE.
  4. [Section 4 / Figure 4] The query returns node_1.id, node_1.features, node_2.id, node_2.features, but the text does not explain how the returned two-hop neighbours are associated with their seed nodes in the training loop. Clarify the mapping from src_id to each hop's neighbours.
  5. [Section 5 / Table 2] The table does not state which dataset is used for the single-machine results; from context it appears to be ogbn-papers100M, but this should be explicit in the caption or text.
  6. [Appendix C] The configuration lists Neo4j, Kùzu, PyTorch, and PyG versions, but does not give the exact dataset split, evaluation metric, or model hyperparameters (e.g., hidden dimension, dropout, learning rate) used for the 58% accuracy figure in Section 5.3. Please add these details for reproducibility.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity; the paper is an engineering mapping of GNN sampling to graph-database queries, validated by external benchmarks.

full rationale

The paper does not derive a mathematical result from first principles; its contribution is an engineering mapping: in-memory neighbour sampling and feature retrieval are replaced by Cypher queries executed by Neo4j. The central claims are supported by measured comparisons against external baselines (standard in-memory PyG and embedded Kùzu) in Tables 2 and 3, not by a derivation that re-imports its own inputs. The sanity checks in Section 5.1 and Appendix D validate the query implementation against row counts and degree distributions, rather than assuming the paper's conclusion. The only arguable weakness is semantic drift: the global ORDER BY rand() LIMIT $MAX_NEIGHBOURS in Figure 4 is not the per-node, per-layer uniform sampling defined by GraphSAGE in Equation 2, and the paper explicitly acknowledges this as an optimization rather than an equivalence. That is a fidelity and correctness concern, not circularity, because the paper does not derive its memory or speed claims from that equivalence; it measures them directly. No fitted parameter is renamed as a prediction, no load-bearing self-citation appears, and no equation reduces by construction to its own target claim. The 8 GB single-machine memory result may be under-specified with respect to the Neo4j server's configured 32 GB heap and page cache, but that is an experimental-validity issue outside the scope of circularity analysis.

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

The paper introduces no new physical or mathematical entities. It relies on database query engine behaviors (random sampling via ORDER BY rand(), caching-based determinism, co-located storage, horizontal scaling) as domain assumptions, and uses three hand-chosen experimental hyperparameters (batch size, neighborhood budget, epochs) that affect the reported results.

free parameters (3)
  • MAX_NEIGHBOURS = 144 (12x12 for two-hop)
    Hand-chosen sampling budget used in all experiments; affects model quality and query cost, not fitted to data.
  • batch_size = 512, 1024, 8192
    Experimental hyperparameter varied across runs; not fitted to data, but affects reported epoch times.
  • num_epochs = 10
    All model accuracy results are after 10 epochs without hyperparameter tuning.
assumptions (5)
  • domain assumption ORDER BY rand() LIMIT n produces a uniformly random sample of rows from the matched subgraph.
    Section 4: the paper relies on the Neo4j query engine behaving this way, citing caching behavior for determinism. Not formally guaranteed by the query language.
  • domain assumption Repeated executions of the same sampling query with the same seed nodes return the same ordering because of database caching.
    Section 4, used to justify that the random ordering is stable enough for reproducible sampling.
  • domain assumption Node attributes are co-located with node IDs in graph database storage, making feature retrieval efficient.
    Section 4, Feature retrieval, citing Neo4j storage format.
  • domain assumption Graph databases support horizontal scaling for OLAP workloads, which provides partitioning for distributed GNN training without explicit graph partitioning.
    Section 4, Distributed training, citing graph sharding references. Used to claim distributed training is 'almost for free'.
  • domain assumption The query engine can execute multi-hop pattern matching efficiently enough for GNN sampling.
    Section 4, Multi-hop sampling; the paper claims chaining hops exploits the query engine's native multi-hop execution.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Graph Neural Networks on Graph Databases." pith.science (2026). https://pith.science/paper/2HUGA36R

@misc{pith2026241111375,
  author       = {Pith},
  title        = {Pith review of: Graph Neural Networks on Graph Databases},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/2HUGA36R}},
  note         = {Machine review of arXiv:2411.11375}
}
read the original abstract

Training graph neural networks on large datasets has long been a challenge. Traditional approaches include efficiently representing the whole graph in-memory, designing parameter efficient and sampling-based models, and graph partitioning in a distributed setup. Separately, graph databases with native graph storage and query engines have been developed, which enable time and resource efficient graph analytics workloads. We show how to directly train a GNN on a graph DB, by retrieving minimal data into memory and sampling using the query engine. Our experiments show resource advantages for single-machine and distributed training. Our approach opens up a new way of scaling GNNs as well as a new application area for graph DBs.

Figures

Figures reproduced from arXiv: 2411.11375 by the authors.

Figure 1
Figure 1. An example labelled property graph. Simple citation graphs such as cora[17] or ogbn￾papers100M[18] can be modelled by such schema. MATCH (n:PAPER)-[:CITES]->(m:PAPER) RETURN DISTINCT m SELECT DISTINCT p.* FROM PAPERS p JOIN CITES c ON p.id = c. cited_paper_id [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. Left: A Cypher query that returns all papers that are cited by at least one other paper. Right: An equivalent SQL query, assuming a reasonable table schema, such as one table PAPERS with properties columns and a second table CITES with columns citing_paper_id and cited_paper_id. le : E → P(E) the label assignment function on edges, K the set of keys (attribute or property names), W the set of values (attribute or pr… view at source ↗
Figure 3
Figure 3. Cypher query that returns all relevant metadata for all nodes. 3 Related Work To the best of our knowledge, there is no previous work that trains a GNN directly on a graph database leveraging its query engine. There are several preliminary work that attempts to integrate graph DBs with ML workflows. Kùzu [30] extended PyG’s default featureStore and graphStore. Being an embedded graph DBMS, the entire graph is loaded… view at source ↗
Figures from the paper (5 more)
Figure 4
Figure 4. Figure 4: A Cypher query template that samples two-hop neighbourhoods of given seed nodes. Features of sampled nodes are returned in the same step. Since there is no keyword in Cypher that is equivalent to SAMPLE, it is not immediately obvious how sampling can be done as part of…
Figure 5
Figure 5. Figure 5: Our distributed training architecture. One graph database acts as a central graph and feature store. Multiple training processes can concurrently sample from the DB with no overhead. Our architecture closely mimics that of PyTorch Distributed Data Parallel[6] and appli…
Figure 6
Figure 6. Figure 6: shows an example Cypher query that returns all relevant edge metadata. MATCH (a)-[r]->(b) WITH DISTINCT type(r) AS EdgeType, labels(a)[0] AS SourceType, labels(b)[0] AS TargetType, r WITH EdgeType, SourceType, TargetType, collect(distinct keys(r)) AS AllKeys, count(r) …
Figure 7
Figure 7. Figure 7: shows a Cypher query that performs one-hop neighbourhood sampling. The nodes returned can be used as seed nodes for subsequent sampling on the next hop. MATCH (node_src:PAPER)-[rel:CITES]-> (node_dst:PAPER) WHERE id(node_src) IN $SEED_NODES RETURN id(node_dst), rand() …
Figure 8
Figure 8. Figure 8: Empirical distribution of sampled nodes using query template [PITH_FULL_IMAGE:figures/full_fig_p014_8.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

55 extracted references · 39 canonical work pages

  1. [1]

    Fineman, Matteo Frigo, John R

    Aydin Buluç, Jeremy T. Fineman, Matteo Frigo, John R. Gilbert, and Charles E. Leiserson. Parallel sparse matrix-vector and matrix-transpose-vector multiplication using compressed sparse blocks. In Proceedings of the Twenty-First Annual Symposium on Parallelism in Al- gorithms and Architectures , page 233–244, 2009. doi: 10.1145/1583991.1584053. URL https:...

  2. [2]

    Hamilton, Zhitao Ying, and Jure Leskovec

    William L. Hamilton, Zhitao Ying, and Jure Leskovec. Inductive representation learning on large graphs. In Neural Information Processing Systems , 2017. URL https://api. semanticscholar.org/CorpusID:4755450. 1, 2

  3. [3]

    Fastgcn: fast learning with graph convolutional networks via importance sampling

    Jie Chen, Tengfei Ma, and Cao Xiao. Fastgcn: fast learning with graph convolutional networks via importance sampling. arXiv preprint arXiv:1801.10247, 2018

  4. [4]

    Layer- dependent importance sampling for training deep and large graph convolutional networks

    Difan Zou, Ziniu Hu, Yewen Wang, Song Jiang, Yizhou Sun, and Quanquan Gu. Layer- dependent importance sampling for training deep and large graph convolutional networks. Advances in neural information processing systems, 32, 2019. 1

  5. [5]

    Distdgl: Distributed graph neural network training for billion-scale graphs

    Da Zheng, Chao Ma, Minjie Wang, Jinjing Zhou, Qidong Su, Xiang Song, Quan Gan, Zheng Zhang, and George Karypis. Distdgl: Distributed graph neural network training for billion-scale graphs. In 2020 IEEE/ACM 10th Workshop on Irregular Applications: Architectures and Algorithms (IA3), pages 36–44. IEEE, 2020. 1, 2

  6. [6]

    Pytorch distributed: experiences on accelerating data parallel training

    Shen Li, Yanli Zhao, Rohan Varma, Omkar Salpekar, Pieter Noordhuis, Teng Li, Adam Paszke, Jeff Smith, Brian Vaughan, Pritam Damania, and Soumith Chintala. Pytorch distributed: experiences on accelerating data parallel training. Proc. VLDB Endow., 13(12):3005–3018, aug 2020. ISSN 2150-8097. doi: 10.14778/3415478.3415530. URL https://doi.org/10. 14778/34154...

  7. [7]

    Fast graph representation learning with pytorch geometric

    Matthias Fey and Jan Eric Lenssen. Fast graph representation learning with pytorch geometric. arXiv preprint arXiv:1903.02428, 2019. 2

  8. [8]

    Deep graph library: A graph-centric, highly-performant package for graph neural networks

    Minjie Wang, Da Zheng, Zihao Ye, Quan Gan, Mufei Li, Xiang Song, Jinjing Zhou, Chao Ma, Lingfan Yu, Yu Gai, Tianjun Xiao, Tong He, George Karypis, Jinyang Li, and Zheng Zhang. Deep graph library: A graph-centric, highly-performant package for graph neural networks. arXiv preprint arXiv:1909.01315, 2019. 2

Show all 55 references
  1. [9]

    TF-GNN: graph neural networks in tensorflow

    Oleksandr Ferludin, Arno Eigenwillig, Martin Blais, Dustin Zelle, Jan Pfeifer, Alvaro Sanchez- Gonzalez, Wai Lok Sibon Li, Sami Abu-El-Haija, Peter Battaglia, Neslihan Bulut, Jonathan Halcrow, Filipe Miguel Gonçalves de Almeida, Pedro Gonnet, Liangze Jiang, Parth Kothari, Silv...

  2. [10]

    A fast and high quality multilevel scheme for parti- tioning irregular graphs

    George Karypis and Vipin Kumar. A fast and high quality multilevel scheme for parti- tioning irregular graphs. SIAM J. Sci. Comput. , 20:359–392, 1998. URL https://api. semanticscholar.org/CorpusID:3628209. 2

  3. [11]

    METIS: A Software Package for Partitioning Unstructured Graphs, Partitioning Meshes, and Computing Fill-Reducing Orderings of Sparse Matrices , September 1998

    George Karypis and Vipin Kumar. METIS: A Software Package for Partitioning Unstructured Graphs, Partitioning Meshes, and Computing Fill-Reducing Orderings of Sparse Matrices , September 1998. 2

  4. [12]

    Communication-free distributed gnn training with vertex cut, 2023

    Kaidi Cao, Rui Deng, Shirley Wu, Edward W Huang, Karthik Subbian, and Jure Leskovec. Communication-free distributed gnn training with vertex cut, 2023. URL https://arxiv. org/abs/2308.03209. 2, 5

  5. [13]

    Scalable and efficient full-graph gnn training for large graphs

    Xinchen Wan, Kaiqiang Xu, Xudong Liao, Yilun Jin, Kai Chen, and Xin Jin. Scalable and efficient full-graph gnn training for large graphs. Proc. ACM Manag. Data, June 2023. 2, 9

  6. [14]

    Bytegnn: efficient graph neural network training at large scale

    Chenguang Zheng, Hongzhi Chen, Yuxuan Cheng, Zhezheng Song, Yifan Wu, Changji Li, James Cheng, Hao Yang, and Shuai Zhang. Bytegnn: efficient graph neural network training at large scale. Proc. VLDB Endow., page 1228–1242, February 2022. 2, 9

  7. [15]

    Foundations of modern query languages for graph databases, 2017

    Renzo Angles, Marcelo Arenas, Pablo Barcelo, Aidan Hogan, Juan Reutter, and Domagoj Vrgoc. Foundations of modern query languages for graph databases, 2017. URL https: //arxiv.org/abs/1610.06264. 2 10 Graph Neural Networks on Graph Databases

  8. [16]

    https://www.w3.org/RDF/, 2014

    RDF. https://www.w3.org/RDF/, 2014. 2

  9. [17]

    Automating the construction of internet portals with machine learning

    Andrew Kachites McCallum, Kamal Nigam, Jason Rennie, and Kristie Seymore. Automating the construction of internet portals with machine learning. Information Retrieval, 3(2):127–163,

  10. [18]

    Open graph benchmark: Datasets for machine learning on graphs

    Weihua Hu, Matthias Fey, Marinka Zitnik, Yuxiao Dong, Hongyu Ren, Bowen Liu, Michele Catasta, and Jure Leskovec. Open graph benchmark: Datasets for machine learning on graphs. Advances in neural information processing systems, 33:22118–22133, 2020. 3, 4, 6

  11. [19]

    Cypher: An evolving query language for property graphs

    Nadime Francis, Alastair Green, Paolo Guagliardo, Leonid Libkin, Tobias Lindaaker, Victor Marsault, Stefan Plantikow, Mats Rydberg, Petra Selmer, and Andrés Taylor. Cypher: An evolving query language for property graphs. In Gautam Das, Christopher M. Jermaine, and Philip A. Be...

  12. [20]

    Formal semantics of the language cypher

    Nadime Francis, Alastair Green, Paolo Guagliardo, Leonid Libkin, Tobias Lindaaker, Victor Marsault, Stefan Plantikow, Mats Rydberg, Martin Schuster, Petra Selmer, and Andrés Taylor. Formal semantics of the language cypher. CoRR, abs/1802.09984, 2018. URL http://arxiv. org/abs/...

  13. [21]

    opencypher: New directions in property graph querying

    Alastair Green, Martin Junghanns, Max Kießling, Tobias Lindaaker, Stefan Plantikow, and Petra Selmer. opencypher: New directions in property graph querying. In Michael H. Böhlen, Reinhard Pichler, Norman May, Erhard Rahm, Shan-Hung Wu, and Katja Hose, editors,Pro- ceedings of ...

  14. [22]

    https://www.iso.org/standard/76120.html, 2024

    GQL. https://www.iso.org/standard/76120.html, 2024. 3

  15. [23]

    Graph pattern matching in GQL and SQL/PGQ

    Alin Deutsch, Nadime Francis, Alastair Green, Keith Hare, Bei Li, Leonid Libkin, Tobias Lindaaker, Victor Marsault, Wim Martens, Jan Michels, Filip Murlak, Stefan Plantikow, Petra Selmer, Hannes V oigt, Oskar van Rest, Domagoj Vrgoc, Mingxi Wu, and Fred Zemke. Graph pattern ma...

  16. [24]

    https://neo4j.com/

    Neo4j. https://neo4j.com/. 3, 5

  17. [25]

    https://arangodb.com/

    ArangoDB. https://arangodb.com/. 3

  18. [26]

    https://www.tigergraph.com/

    TigerGraph. https://www.tigergraph.com/. 3

  19. [27]

    https://www.w3.org/TR/sparql11-query/, 2013

    SPARQL. https://www.w3.org/TR/sparql11-query/, 2013. 3

  20. [28]

    Rdfox: A highly-scalable rdf store

    Yavor Nenov, Robert Piro, Boris Motik, Ian Horrocks, Zhe Wu, and Jay Banerjee. Rdfox: A highly-scalable rdf store. In International Workshop on the Semantic Web , 2015. URL https://api.semanticscholar.org/CorpusID:7608029. 3

  21. [29]

    https://aws.amazon.com/neptune/

    AWS Neptune. https://aws.amazon.com/neptune/. 3

  22. [30]

    Kùzu: Graph learning applications need a modern graph DBMS

    Ziyi Chen, Xiyang Feng, Guodong Jin, Chang Liu, and Semih Salihoglu. Kùzu: Graph learning applications need a modern graph DBMS. In The Second Learning on Graphs Conference ,

  23. [31]

    Neural graph databases

    Maciej Besta, Patrick Iff, Florian Scheidl, Kazuki Osawa, Nikoli Dryden, Michal Podstawski, Tiancheng Chen, and Torsten Hoefler. Neural graph databases. In Learning on Graphs Conference, pages 31–1. PMLR, 2022. 4

  24. [32]

    Petar Ristoski, Jessica Rosati, T. D. Noia, Renato De Leone, and Heiko Paulheim. Rdf2vec: Rdf graph embeddings and their applications. Semantic Web, 10:721–752, 2019. URL https: //api.semanticscholar.org/CorpusID:150293718. 4

  25. [33]

    node2vec: Scalable feature learning for networks

    Aditya Grover and Jure Leskovec. node2vec: Scalable feature learning for networks. In Proceedings of the 22nd ACM SIGKDD international conference on Knowledge discovery and data mining, pages 855–864, 2016. 4

  26. [34]

    Neural graph reasoning: Complex logical query answering meets graph databases

    Hongyu Ren, Mikhail Galkin, Michael Cochez, Zhaocheng Zhu, and Jure Leskovec. Neural graph reasoning: Complex logical query answering meets graph databases. arXiv preprint arXiv:2303.14617, 2023. 4 11 Graph Neural Networks on Graph Databases

  27. [35]

    Relational deep learning: Graph representation learning on relational databases

    Matthias Fey, Weihua Hu, Kexin Huang, Jan Eric Lenssen, Rishabh Ranjan, Joshua Robinson, Rex Ying, Jiaxuan You, and Jure Leskovec. Relational deep learning: Graph representation learning on relational databases. CoRR, abs/2312.04615, 2023. doi: 10.48550/ARXIV .2312. 04615. URL...

  28. [36]

    The shift from models to compound ai systems

    Matei Zaharia, Omar Khattab, Lingjiao Chen, Jared Quincy Davis, Heather Miller, Chris Potts, James Zou, Michael Carbin, Jonathan Frankle, Naveen Rao, and Ali Ghodsi. The shift from models to compound ai systems. https://bair.berkeley.edu/blog/2024/02/18/ compound-ai-systems/, 2024. 4

  29. [37]

    Retrieval-augmented generation for knowledge-intensive nlp tasks

    Patrick Lewis, Ethan Perez, Aleksandra Piktus, Fabio Petroni, Vladimir Karpukhin, Naman Goyal, Heinrich Küttler, Mike Lewis, Wen-tau Yih, Tim Rocktäschel, et al. Retrieval-augmented generation for knowledge-intensive nlp tasks. Advances in Neural Information Processing Systems...

  30. [38]

    From local to global: A graph rag approach to query-focused summarization

    Darren Edge, Ha Trinh, Newman Cheng, Joshua Bradley, Alex Chao, Apurva Mody, Steven Truitt, and Jonathan Larson. From local to global: A graph rag approach to query-focused summarization. arXiv preprint arXiv:2404.16130, 2024

  31. [39]

    Gnn-rag: Graph neural retrieval for large language model reasoning

    Costas Mavromatis and George Karypis. Gnn-rag: Graph neural retrieval for large language model reasoning. arXiv preprint arXiv:2405.20139, 2024. 4

  32. [40]

    Exploration of approaches for in- database ml

    Steffen Kläbe, Stefan Hagedorn, and Kai-Uwe Sattler. Exploration of approaches for in- database ml. In International Conference on Extending Database Technology, 2023. URL https://api.semanticscholar.org/CorpusID:253270276. 4

  33. [41]

    Learning models over relational data using sparse tensors and functional dependencies

    Mahmoud Abo Khamis, Hung Q Ngo, XuanLong Nguyen, Dan Olteanu, and Maximilian Schleich. Learning models over relational data using sparse tensors and functional dependencies. arXiv preprint arXiv:1703.04780, 2017

  34. [42]

    The relational data borg is learning

    Dan Olteanu. The relational data borg is learning. arXiv preprint arXiv:2008.07864, 2020. 4

  35. [43]

    https://www.pinecone.io/

    Pinecone. https://www.pinecone.io/. 5

  36. [44]

    The graph database interface: Scaling online transactional and analytical graph workloads to hundreds of thousands of cores

    Maciej Besta, Robert Gerstenberger, Marc Fischer, Michal Podstawski, Nils Blach, Berke Egeli, Georgy Mitenkov, Wojciech Chlapek, Marek Michalewicz, Hubert Niewiadomski, et al. The graph database interface: Scaling online transactional and analytical graph workloads to hundreds...

  37. [45]

    Powerlyra: Differentiated graph computation and partitioning on skewed graphs

    Rong Chen, Jiaxin Shi, Yanzhe Chen, Binyu Zang, Haibing Guan, and Haibo Chen. Powerlyra: Differentiated graph computation and partitioning on skewed graphs. ACM Trans. Parallel Comput., jan 2019. 5

  38. [46]

    G-tran: Making distributed graph transactions fast

    Hongzhi Chen, Changji Li, Chenguang Zheng, Chenghuan Huang, Juncheng Fang, James Cheng, and Jian Zhang. G-tran: Making distributed graph transactions fast. arXiv preprint arXiv:2105.04449, 2021. 5

  39. [47]

    Kùzu graph database management system

    Guodong Jin, Xiyang Feng, Ziyi Chen, Chang Liu, and Semih Salihoglu. Kùzu graph database management system. In 13th Conference on Innovative Data Systems Research, CIDR 2023, Amsterdam, The Netherlands, January 8-11, 2023. www.cidrdb.org, 2023. URL https://www. cidrdb.org/cidr...

  40. [48]

    https://graph500.org/

    Graph500. https://graph500.org/. 8

  41. [49]

    Sampling meth- ods for efficient training of graph convolutional networks: A survey

    Xin Liu, Mingyu Yan, Lei Deng, Guoqi Li, Xiaochun Ye, and Dongrui Fan. Sampling meth- ods for efficient training of graph convolutional networks: A survey. IEEE/CAA Journal of Automatica Sinica, 9(2):205–234, 2021. 9

  42. [50]

    Magnn: Metapath aggregated graph neural network for heterogeneous graph embedding

    Xinyu Fu, Jiani Zhang, Ziqiao Meng, and Irwin King. Magnn: Metapath aggregated graph neural network for heterogeneous graph embedding. In Proceedings of the web conference 2020, pages 2331–2341, 2020. 9

  43. [51]

    Het- erogeneous graph attention network

    Xiao Wang, Houye Ji, Chuan Shi, Bai Wang, Yanfang Ye, Peng Cui, and Philip S Yu. Het- erogeneous graph attention network. In The world wide web conference, pages 2022–2032, 2019

  44. [52]

    Chawla, and Ananthram Swami

    Yuxiao Dong, Nitesh V . Chawla, and Ananthram Swami. metapath2vec: Scalable representation learning for heterogeneous networks. In Proceedings of the 23rd ACM SIGKDD International Conference on Knowledge Discovery and Data Mining, page 135–144, 2017. doi: 10.1145/ 3097983.3098...

  45. [53]

    Chuxu Zhang, Dongjin Song, Chao Huang, Ananthram Swami, and Nitesh V . Chawla. Heteroge- neous graph neural network. InProceedings of the 25th ACM SIGKDD International Conference on Knowledge Discovery & Data Mining, page 793–803, 2019. doi: 10.1145/3292500.3330961. URL https:...

  46. [2000]

    doi: 10.1023/A:1009953814988

    ISSN 1573-7659. doi: 10.1023/A:1009953814988. URL https://doi.org/10.1023/ A:1009953814988. 3

  47. [2023]

    URL https://openreview.net/forum?id=Eg3MthXzeT. 4

Pith tools

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