PyTorch Geometric Temporal: A Model Zoo and Data Loader for Temporal Graphs
PyTorch Geometric Temporal: Spatiotemporal Signal Processing with Neural Machine Learning Models (CIKM 2021)
At a glance
- What is it?
- The library collects published spatiotemporal GNN methods and pairs them with snapshot iterators and benchmark datasets. Its value is breadth and plumbing, not performance claims, and its cost is a dependency chain it does not control.
- Who is it for?
- Adopt it if you already build on PyTorch Geometric and want published spatiotemporal architectures plus a snapshot iterator without writing either yourself. Do not adopt it if your graph is static or your pipeline is not PyTorch based, since the models import from torch_geometric and the loaders return its Data objects.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 108 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap between static GNN libraries and time series tooling
Most graph neural network libraries assume the graph is fixed. You build one adjacency, one feature matrix, and train. Most time series libraries assume the observations are independent series with no edges between them. Spatiotemporal problems sit in the middle: traffic sensors on a road network, epidemiological counts across regions, energy production across a grid. The graph exists, and it also evolves. PyTorch Geometric Temporal is aimed at that middle. It describes itself as a temporal extension library for PyTorch Geometric, and the README lists its audience implicitly through the domains it ships data for: epidemiological forecasting, sharing economy, energy production and web traffic management. If your problem has a node set, edges between nodes, and a value per node per timestep, this is the shape of library you are looking for. If your graph is static, the base PyTorch Geometric library already covers you and this adds a dependency you do not need.
What the snapshot iterator actually does
The core abstraction in the README is the temporal snapshot iterator. Rather than handing you a tensor of shape (time, nodes, features), the library exposes the graph as a sequence of snapshots, so each training step sees one graph state. That matters because recurrent models here are not recurrent over a flattened sequence. They are recurrent over graph convolutions applied per snapshot. The README's example makes this concrete: a recurrent graph convolutional network built from two consecutive GConvGRU cells and a linear layer, with the cells instantiated as GConvGRU(node_features, 32, 5) and GConvGRU(32, 16, 5). The third argument is the number of Chebyshev filter terms used in the graph convolution, so the model is doing spectral-style aggregation at each timestep and passing the result through a GRU cell. The data flow is therefore: loader yields a snapshot, the convolution aggregates over neighbours, the GRU carries hidden state forward, and the linear layer maps the final hidden width to your output. The library also provides a train-test splitter, and the README distinguishes incremental training from cumulative training as two case study patterns, with epidemiological forecasting as the incremental example and web traffic management as the cumulative one. That distinction is a design choice worth understanding before you pick a model, because it changes whether the model sees the graph growing over time or the full graph at each step.
Installation and the version coupling you inherit
The package is distributed on PyPI as torch-geometric-temporal, which is the name to use in a requirements file or a pip install. The README does not reproduce a full install command in the material available here, so check the documentation site for the current pinned combination before installing. That caution is not generic. Release 0.54.0 is titled "Simplify test environment and installation", and 0.55.0 covers "Bug fixes in import and data loading". Both titles point at the same friction: the package sits on top of PyTorch and PyTorch Geometric, and version drift between those three is the most likely source of an ImportError on first run. The library also interfaces with PyTorch Lightning, and the README points to an introductory example at examples/recurrent/lightning_example.py for CPU, single GPU and multi-GPU training. If you already train with Lightning, that example is the fastest way to see how the snapshot iterator feeds a LightningModule. If you do not, the plain PyTorch path in the README example is short enough to copy directly.
Index-batching and what the 2025 releases changed
The 0.56.0 release is labelled "Index-Batching", and the README describes it as a batching technique that improves spatiotemporal memory efficiency without any impact on accuracy. The examples live under examples/indexBatching, and the README states they let users customize training to scale to larger datasets than previously possible. The same material says the library supports memory-efficient distributed data parallel training using Dask-DDP in combination with index-batching, and cites a 2025 arXiv paper, PGT-I, on scaling spatiotemporal GNNs with memory-efficient distributed training. Two things are worth separating here. The repository ships the technique and the examples. The accuracy claim is made in the README, and the underlying evaluation is in a paper the README links, not in this repository's test suite as far as the material shows. If memory is your bottleneck, examples/indexBatching is the directory to read first, and the Dask-DDP combination is the documented path for going beyond a single device. Note the release cadence too: 0.54.0 landed in September 2022, 0.55.0 in February 2025, and 0.56.0 in March 2025. The project went roughly two and a half years between the 2022 release and the next one, then shipped twice in two months. Plan your upgrade testing around that pattern rather than assuming steady incremental change.
Where the library stops being the right tool
The models here are implementations of published architectures, and the README frames the library that way: it consists of methods from a variety of published research papers. That is a useful property for reproducing a paper and a poor one for squeezing accuracy out of a well-studied dataset, because nothing in the material suggests the implementations are tuned beyond what the papers specify. A second limitation is scope. The README describes dynamic and temporal geometric deep learning, embedding and spatio-temporal regression. If your task is node classification on a graph that never changes, none of this applies, and the extra dependency on torch_geometric is pure overhead. A third is the dependency chain itself. The library is an extension of PyTorch Geometric, so a breaking change upstream is a breaking change here, and the release titles about import and data loading bugs indicate that has happened. The fourth is documentation depth. The README is largely a pointer to the ReadTheDocs site, and the material available here does not document the constructor arguments beyond the example's third positional argument. Expect to read source for anything the example does not cover.
How this differs from building on PyTorch Geometric directly
The obvious alternative is PyTorch Geometric itself. It gives you message passing, sampling and the Data and HeteroData containers, and it is the layer this project builds on. The difference is what each assumes about time. PyTorch Geometric has no snapshot abstraction: you would write your own loop that slices a time-indexed dataset into per-step graphs, manage the hidden state yourself, and reimplement whichever recurrent convolution you need from the paper. That is a real amount of code, and it is exactly the code this library supplies. The trade is control. Building directly means you choose the batching strategy and the memory layout without inheriting someone else's iterator semantics, and you avoid a third package in the version matrix. Choosing this library means you accept its snapshot representation and its model implementations in exchange for not writing them. For a team that already has a PyTorch Geometric pipeline and a custom temporal loop in production, swapping in this library is a rewrite of the data path, not a drop-in. For a team starting a spatiotemporal project, the loader and the model zoo are the reason to pick it.
Licence, maintenance and what to verify before you commit
The repository is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is a permissive licence, and it is compatible with the rest of a typical PyTorch stack. It is not legal advice; if you are shipping a product that embeds the library, have counsel confirm the notice requirements and check the licences of the bundled datasets separately, since dataset terms are frequently stricter than the code that loads them. On maintenance, the last push recorded is 2026-05-30 and the repository is not archived, so the project is active. The recent release history shows one long gap followed by two releases in early 2025, which suggests maintenance is bursty rather than continuous. The concrete things to verify before adopting: the exact torch and torch_geometric versions the current documentation pins, whether the specific bundled dataset you need is present in the loader you intend to use, and whether examples/indexBatching covers your memory profile or whether you also need the Dask-DDP path. Those three checks, run against your own environment, will tell you more than any summary of the feature list.
Editorial conclusion
Adopt it if you already build on PyTorch Geometric and want published spatiotemporal architectures plus a snapshot iterator without writing either yourself. Do not adopt it if your graph is static or your pipeline is not PyTorch based, since the models import from torch_geometric and the loaders return its Data objects. Before committing, check the pinned torch and torch_geometric versions in the installation instructions against your environment, and confirm which bundled datasets you actually need, because the index-batching examples are the only path the 2025 releases mention for scaling past previous memory limits.
Community notes