Source-linked AI summary
Towards Training and Inference of Graph Neural Networks in Graph Databases
Victor Pekkari, Harry Wik, Alfred Clemedtson, Borun Shi, Xuan-Son Vu
TL;DR
GNN pipelines commonly rely on in-memory storage and ad hoc processing, while direct use of graph databases remains little studied. This paper runs GNN training operations and inference in graph databases, reporting faster UDP sampling than Cypher and low-memory in-database inference. Its scope includes GraphSAGE and GraphSAINT sampling and excludes layerwise sampling, distributed systems, and GPUs.
Problem
GNN training commonly uses ad hoc pipelines, and existing work has rarely used graph databases directly for training or inference despite the sampling and feature-retrieval stages involved.
Source: §1 · p. 1Method
The paper treats GNN computation as a database workload, implementing training sampling and feature retrieval in graph databases and full forward-pass inference within the database.
Source: §1 · p. 1, §3.2 · p. 3Results
3.8x speedup on ogbn-papers100M and 5.2x on ogbn-products: UDP sampling beat Cypher; in-DB UDP inference handled 2048 nodes in <1s with 32GB RAM when full-graph PyG loading OOM.
Source: §4.3 · p. 5Takeaways & Limitations
The in-database inference approach is particularly useful for real-world graphs already stored in graph databases that may evolve over time.
Source: §1 · p. 1The study covers GraphSAGE and GraphSAINT, not layerwise sampling, distributed systems, or GPUs; exact resource differences may vary across non-Neo4j disk-based graph databases.
Source: §5 · p. 5
Abstract
from arXiv · showhide
Graph Neural Networks on large graphs commonly rely on in-memory graph storage with ad hoc data processing pipelines for both training and inference. Graph databases provide scalable storage and efficient traversal for graphs that can evolve over time, but their applicability in GNN training and inference are rarely studied. We show that graph DBs can be used in GNN training and inference directly, executing sampling, feature retrieval, and even the full forward pass. We show different GNN training pipelines can perform on-the-fly sampling and retrieval in graph DBs using Cypher. We further provide optimisations that speed up the training process by \~2.5x while maintaining the same accuracy. We illustrate that fully in-DB inference is possible, independent of how the GNNs are trained. Our inference setup can be >10x faster than cold loading the graph into RAM with no extra memory overhead on real-world graphs. Our work lays the foundation for in-graph-DB GNN training and inference.
1 Introduction
GNN training requires sampling local neighborhoods and retrieving their features, yet graph databases have rarely been used directly in GNN pipelines. This section frames GNN computation as a database workload and presents graph-database approaches to training and inference.
1 Introduction
- Neighborhood explosion in K-layer GNNs motivates sampling K-hop neighborhoods, adding topology sampling and feature retrieval to training.These stages operate on subsets of the full K-hop neighborhood.Source: §1 · p. 1
- GNN and graph-database research have had little synergy, with training relying on ad hoc pipelines and few systems-level inference improvements.Prior work did not directly use existing graph databases in the training or inference pipeline.Source: §1 · p. 1
- The paper treats GNN forward computation as a database workload of neighborhood-based retrieval and aggregation.It builds on an earlier proof of concept to couple GNN training and inference more closely with graph databases.Source: §1 · p. 1
- Graph databases support GNN training forward computation, including sampling and feature retrieval, through Cypher queries or user-defined procedures.The paper benchmarks implementation options and proposes pre-aggregation to speed training for certain graph and GNN classes; it also presents fully in-database inference independent of how the GNN was trained.Source: §1 · p. 1
2 Preliminary
The preliminary section introduces message-passing GNNs and the storage and systems trade-offs around their training and inference. It then describes graph databases’ storage, query, and procedure capabilities.
2.1 Graph Neural Networks
- Message-passing GNNs use neighborhood messages, aggregation, and an update function to produce a node’s next-layer representation.The aggregation is a permutation-invariant multiset function, such as mean or sum.Source: §2.1 · pp. 1–2
- CSR and CSC support fast neighbor lookup but must be rebuilt when graphs change, whereas COO accepts appended edges but requires scanning the edge list for neighbors.The passage describes these as trade-offs among common in-memory graph formats.Source: §2.1 · p. 2
- Distributed GNN training partitions graphs and features across machines for parallel throughput, at the cost of hardware, maintenance, and partitioning overhead.Partitioning can also duplicate data or slow queries; GPU sampling does not remove the challenge of optimizing utilization and throughput.Source: §2.1 · p. 2
- Because inference is typically on-demand, keeping the full graph in RAM between requests can be unnecessarily expensive when low latency is not crucial.Keeping the graph on disk between requests could reduce hardware cost while providing acceptable inference latency.Source: §2.1 · p. 2
2.2 Graph Databases
- Graph databases store nodes, edges, types, and properties, and provide traversal through query engines and user-defined procedures.Cypher expresses graph patterns with filters, transformations, and aggregations; procedures allow explicit control of traversal and retrieval through the database kernel.Source: §2.2 · p. 2
3 System Design
The design shifts selected GNN forward computation into graph databases while retaining learning computations in a separate training process. It evaluates database-backed training pipelines and inference architectures that place progressively more inference inside the database.
3.1 Training Pipelines
- For each mini-batch, the graph database samples the on-disk graph and returns the sampled subgraph and node features; the training process runs the forward pass, loss calculation, and weight update.Only the sampled subgraph needs to reside in the training process's memory.Source: §3.1 · p. 2
- Training variants progress from declarative Cypher queries to database UDPs and first-layer parameter-free pre-aggregation, which reduces transferred feature vectors while learnable computations and backpropagation remain in the training process.Pre-aggregation returns vectors for the learnable model components and pre-aggregated neighborhood vectors for the outermost sampled nodes.Source: §3.1 · p. 2
3.2 Inference Pipelines
- Inference architectures range from cold or hot in-memory references and database-backed neighborhood sampling to complete forward passes inside the database using UDPs or Cypher.The Cypher variants use either reduce() or Cypher 25 native vector operations for matrix multiplication and aggregation.Source: §3.2 · p. 3
- The authors state that prior work treats graph databases as storage for exported data and does not study fully in-database GNN inference.Their in-database Cypher implementation executes sampling and the full forward pass in a single declarative query.Source: §3.2 · p. 3
4 Experiments
The experiments compare graph-database training and inference pipelines with in-memory PyG, testing correctness and measuring where execution and data transfer costs arise. UDPs and pre-aggregation offer different benefits, while fully in-database inference can avoid loading the full graph into RAM.
4.1 Setup
- The experiments use one machine with 32 vCPUs and 256 GB RAM, and compare five datasets with fixed hyperparameters.Neo4j runs on four NVMe drives in RAID 0; database-backed pipelines store properties as byte arrays for transfer and decoding.Source: §4.1 · p. 3
- Validation accuracy converges similarly across PyG, Cypher, and UDP implementations for GraphSAGE and GraphSAINT on Cora.KL divergence between node and edge distributions is below 0.01 for both samplers in Cypher and UDP.Source: §4.1 · p. 3, Figure 2 · p. 3
4.2.1 Sampling: Cypher vs UDP.
- Cypher sampling spends substantial time building and sorting intermediate lists, while Expand(All) retrieves neighboring vertices and can expand more nodes than sampling needs.For fanout [10, 5] and batch_size=128, Expand produces over 10,000 rows versus 7,808 necessary nodes.Source: §4.2.1 · p. 3, Figure 4 · p. 4, Figure 5 · p. 4
- UDP sampling is 3.8x faster than Cypher on ogbn-papers100M and 5.2x faster on ogbn-products.The paper attributes Cypher overhead to materialized intermediate tuples; UDP reservoir sampling uses O(k) additional memory for a sample of size k.Source: §4.2.1 · p. 3, Figure 3 · p. 4
- For feature retrieval, UDP’s single-byte-array serialization reduces communication overhead more than query execution time.Cypher retrieval is relatively simple and already executes efficiently; the main opportunity is reducing per-feature transfer overhead.Source: §4.2.2 · p. 4
4.2.3 Aggregation in the graph database (Pre-aggregation).
- Pre-aggregation reduces data sent for all five datasets, but speeds feature fetching only when feature vectors are high-dimensional.It reduces transferred data by about 40%–60% for fanout [10, 5]; on CoAuthor Physics, with 8,415-dimensional features, feature-fetching latency is more than halved.Source: §4.2.3 · pp. 4–5, Figure 6 · p. 5, Figure 7 · p. 5
4.3 Inference
- With 32 GB RAM, in-DB UDP inference on 2,048 nodes finishes in <1s, while full-graph PyG loading runs out of memory.With 128 GB RAM, the same in-DB inference takes ~0.1s; in-DB inference materializes only inference nodes and one frontier layer.Source: §4.3 · p. 5
- In-DB inference executes the full forward pass independently of the training library and leaves the rest of the graph on disk.Models can be exported, translated to Cypher or UDP, and supplied with weights as parameters.Source: §4.3 · p. 5
5 Conclusion
The paper concludes that graph databases can execute GNN training and inference, with UDPs and pre-aggregation optimizing training in some settings. Its evaluation scope is limited to selected samplers and excludes distributed systems and GPUs.
5 Conclusion
- The evaluation includes GraphSAGE and GraphSAINT sampling but not layerwise sampling, distributed training systems, or GPUs.The authors note that exact resource differences may vary for other non-Neo4j disk-based graph databases.Source: §5 · p. 5
- Figure 9 reports that storing embeddings as byte[] reduces driver time by more than half compared with float64[].The stated cause is a large reduction in packstream decoding in the Bolt client driver.Source: Figure 9 · p. 6
- Graph databases can execute GNN training and inference, with UDPs and pre-aggregation optimizing training under high-dimensional embeddings and in-DB UDPs providing the most efficient inference.The paper frames this as a new training and inference use case for graph databases.Source: §5 · p. 6
Artifacts
The paper makes its Cypher and UDP implementations, setup materials, and reproducibility scripts available in a public repository.
Artifacts
- The repository includes Cypher and UDP implementations of different GNN layers, setup and reproducibility scripts, and instructions for extending the work.The passage identifies the repository as github.com/harrywik/neo4j-mpgnn-thesis.Source: Artifacts · p. 6
A Neo4j embedding storage format
The embedding-storage discussion contrasts byte[] properties with Neo4j f64[] properties, describing conversion and driver overheads associated with the latter.
A Neo4j embedding storage format
- Storing embeddings as byte[] avoids substantial overhead associated with Neo4j f64[] properties, which require f64-to-f32 conversion and increase TCP payload size.The Bolt driver also converts each incoming f64 into a Python float, while byte buffers can be transferred by bulk memcpy.Source: A Neo4j embedding storage format · p. 6
B Breakdown of training time on ogbn-product
The training-time breakdown for ogbn-products reports significantly higher graph-traversal time for baseline_neo4j.
B Breakdown of training time on ogbn-product
- Graph traversal takes significantly longer for baseline_neo4j in the training-time breakdown for a large, dense graph.Figure 10 presents the ogbn-products breakdown.Source: B Breakdown of training time on… · p. 6