Redis
Translating openCypher queries into sparse matrix operations over semirings eliminates serial node-by-node pointer traversal, reducing CPU cache thrashing and completing complex searches in milliseconds.
AI-assisted summary of Lower Latency Graph Queries in Cypher with Redis GraphRoi Lipman, Redis LabsTim Davis, Texas A&M U — original source. Check the original for full context.
Source published:
Key ideas
- RedisGraph adopts SuiteSparse:GraphBLAS to map Cypher queries directly onto linear algebra operations over sparse adjacency matrices. (26:05)
- Sparse matrices overcome quadratic memory bottlenecks, allowing real-world graphs like Facebook's 2-billion-user network to track non-zero relationships without allocating trillions of empty cells. (2:35)
- GraphBLAS generalizes linear algebra using customizable semirings, turning standard matrix multiplication into algorithms like breadth-first search and shortest paths. (3:38)
- In benchmarks on a 1-million-node, 3-million-edge dataset, RedisGraph executed full neighbor discovery in 50 milliseconds and a 100-target BFS traversal in 1 millisecond. (31:58)
Detailed notes
## Background Published on YouTube by the Redis channel on May 24, 2018, this presentation features Redis Labs engineer Roi Lipman and Texas A&M University Professor Tim Davis. While no official description or show notes were provided with the upload, the lecture details how RedisGraph achieved low-latency Cypher query processing by replacing traditional pointer-chasing traversals with sparse linear algebra.
## TL;DR The talk presents the architectural transformation of RedisGraph through its integration with SuiteSparse:GraphBLAS. Traditional graph engines process traversals via serial, depth-first pointer chasing that frequently invalidates CPU caches and incurs random memory access penalties. By reframing graph topology as sparse adjacency matrices and mapping graph operations to custom algebraic semirings, the engine executes queries—including multi-hop filters and variable-length paths—as optimized matrix-matrix and matrix-vector multiplications. Tim Davis explains the inner workings of GraphBLAS (including masking, lazy evaluation, and update mechanics like zombies and pending tuples), while Roi Lipman demonstrates how openCypher queries compile into associative matrix chains that yield dramatic latency reductions on multi-million-edge graphs.
## Atmosphere & style The presentation carries the collaborative, intellectually rigorous atmosphere of a top-tier systems conference where cutting-edge academic mathematics meets real-world database engineering. Roi Lipman delivers a structured, practical software engineering narrative, which pairs naturally with Professor Tim Davis's engaging, animated, and humor-laced lecture style. Watching the session feels like witnessing an 'aha!' moment in computer science, as dry linear algebra concepts suddenly unlock elegant, blazingly fast solutions to stubborn systems bottlenecks.
## Bulletin - [26:05](https://www.youtube.com/watch?v=xnez6tloNSQ&t=1565s) RedisGraph adopts SuiteSparse:GraphBLAS to map Cypher queries directly onto linear algebra operations over sparse adjacency matrices. - [02:35](https://www.youtube.com/watch?v=xnez6tloNSQ&t=155s) Sparse matrices overcome quadratic memory bottlenecks, allowing real-world graphs like Facebook's 2-billion-user network to track non-zero relationships without allocating trillions of empty cells. - [03:38](https://www.youtube.com/watch?v=xnez6tloNSQ&t=218s) GraphBLAS generalizes linear algebra using customizable semirings, turning standard matrix multiplication into algorithms like breadth-first search and shortest paths. - [31:58](https://www.youtube.com/watch?v=xnez6tloNSQ&t=1918s) In benchmarks on a 1-million-node, 3-million-edge dataset, RedisGraph executed full neighbor discovery in 50 milliseconds and a 100-target BFS traversal in 1 millisecond.
## Key takeaways - [02:35](https://www.youtube.com/watch?v=xnez6tloNSQ&t=155s) Representing graphs with dense bitwise adjacency matrices breaks down at scale, requiring 125 GB of RAM for just 1 million nodes. - [02:35](https://www.youtube.com/watch?v=xnez6tloNSQ&t=155s) Real-world networks are overwhelmingly sparse, making sparse matrices essential by storing only populated coordinates and treating absent entries implicitly as zero. - [03:38](https://www.youtube.com/watch?v=xnez6tloNSQ&t=218s) Linear algebra and graph algorithms share a mathematical duality through semirings, where substituting addition and multiplication operators yields algorithms like BFS and Bellman-Ford. - [03:38](https://www.youtube.com/watch?v=xnez6tloNSQ&t=218s) GraphBLAS masking acts as a bulk vectorized filter, eliminating procedural nested loops and conditional checks during graph frontier traversals. - [08:49](https://www.youtube.com/watch?v=xnez6tloNSQ&t=529s) Opaque C API data structures allow GraphBLAS to support lazy non-blocking evaluation and seamless offloading to hardware backends like GPUs without changing user-facing code. - [18:38](https://www.youtube.com/watch?v=xnez6tloNSQ&t=1118s) SuiteSparse:GraphBLAS uses 'zombies' and pending tuple queues to avoid constant memory reallocation during dynamic submatrix assignments, outperforming MATLAB's incremental graph updates. - [22:47](https://www.youtube.com/watch?v=xnez6tloNSQ&t=1367s) Traditional depth-first graph traversals suffer from serial execution pipelines and CPU cache misses caused by repeated pointer-chasing and backtracking. - [26:05](https://www.youtube.com/watch?v=xnez6tloNSQ&t=1565s) RedisGraph translates openCypher queries into matrix expressions, using matrix associativity to reorder operations and minimize intermediate non-zero counts. - [29:33](https://www.youtube.com/watch?v=xnez6tloNSQ&t=1773s) Variable-length path queries map directly to summing successive powers of adjacency matrices, merging distinct reachability depths into unified matrix states. - [31:58](https://www.youtube.com/watch?v=xnez6tloNSQ&t=1918s) Distributing graph operations across clusters or threads maps naturally to block matrix multiplication, simplifying distributed scheduling and aggregation. - [36:24](https://www.youtube.com/watch?v=xnez6tloNSQ&t=2184s) High-level analytics like triangle counting implemented in a few lines of GraphBLAS achieve performance within 20% of bespoke, expert-written C code. - [39:47](https://www.youtube.com/watch?v=xnez6tloNSQ&t=2387s) GraphBLAS formalizes over a decade of theoretical research by standardizing an API that bridges numerical linear algebra with graph theory. - [41:58](https://www.youtube.com/watch?v=xnez6tloNSQ&t=2518s) RedisGraph handles node attribute filtering without expensive set scans by encoding index predicates as boolean vectors multiplied directly against adjacency matrices.
## Detailed walkthrough ### [00:00](https://www.youtube.com/watch?v=xnez6tloNSQ&t=0s) Graph Foundations and Representation via Adjacency Matrices
Roi Lipman, an engineer at Redis Labs working on RedisGraph for nearly two years, opens the presentation by grounding the audience in the mathematical and practical definitions of graphs. At its core, a graph consists of a set of nodes representing entities and a set of edges connecting those nodes to represent relationships. In a real-world scenario such as Facebook, nodes correspond to individual users while edges denote friendships between them. When translating this conceptual structure into computer storage, developers typically have several choices. Non-traditional options include relational SQL tables or JSON documents, neither of which was architected for graph traversal. Formal graph representations rely either on adjacency lists or adjacency matrices, with this talk concentrating squarely on the power of adjacency matrices.
An adjacency matrix provides an algebraic layout where rows and columns map directly to nodes in the network. A row $i$ represents node $i$, and a column $j$ corresponds to node $j$. If an edge exists pointing from node $i$ to node $j$, the matrix cell at row $i$, column $j$ holds a value of 1; if no edge exists, the cell holds a 0. Lipman explains that in an idealized implementation, one could attempt to keep memory footprint minimal by allocating just a single bit per cell. Such a compact bitwise structure allows fundamental matrix additions and multiplications to map directly to ultra-fast hardware bitwise operations.
```mermaid flowchart LR accTitle: Adjacency Matrix Representation accDescr: Graph topology mapped directly to row-column entries in a binary adjacency matrix. subgraph Topology["Graph Topology"] N1["Node i"] -->|"Edge (i, j)"| N2["Node j"] end subgraph Matrix["Adjacency Matrix A"] direction TB R1["Row i, Col j = 1 (Connected)"] R2["Row i, Col k = 0 (Disconnected)"] end Topology -->|"Maps to"| Matrix ```
- **Graph primitives**: Nodes model distinct entities; edges model directional or bidirectional relationships. - **Storage mechanisms**: Relational schemas (SQL) and document stores (JSON) contrast with formal models like adjacency lists and adjacency matrices. - **Bitwise dense matrices**: Representing cells with 1 bit allows fast bitwise calculations, but scalability quickly breaks down as vertex counts grow.
---
[02:35](https://www.youtube.com/watch?v=xnez6tloNSQ&t=155s) The Density Bottleneck and the Sparse Matrix Solution
While dense bit matrices yield fast arithmetic, their memory consumption expands quadratically. Lipman demonstrates the math: an ordinary graph with one million nodes requires a dense matrix of one million rows by one million columns. Even when constrained to a single bit per entry, allocating one trillion bits requires 125 gigabytes of memory space. As Lipman explains when assessing this barrier, “This will take a matrix with 1 million rows and 1 million columns summing up to 125 gigabytes of space which basically kills the idea of using matrices to represent graphs.”
Real-world graphs, however, are overwhelmingly sparse, meaning that the number of populated, non-zero entries is minuscule compared to the total dimensions of the matrix. Lipman illustrates this using Facebook's scale: among its roughly two billion users, an average user maintains approximately 338 friends. Constructing a complete dense matrix would require $2 \times 10^9$ squared possible cells, but only $2 \times 10^9 \times 338$ actual edges exist. To avoid wasting gigabytes storing empty links, systems adopt sparse matrices, which track only populated non-zero entries. Any unrecorded coordinate $(i, j)$ is implicitly evaluated as zero. To handle these computations efficiently, the team turns to GraphBLAS, leading Lipman to introduce Professor Tim Davis of Texas A&M University to explain the library's design.
- **Dense storage limitation**: Storing a 1,000,000-node graph in a flat bit matrix demands 125 GB of RAM. - **Facebook graph sparsity**: 2 billion nodes with an average degree of 338 yields $6.76 \times 10^{11}$ non-zero entries out of $4 \times 10^{18}$ total matrix entries. - **Sparse matrix rule**: Memory is consumed exclusively by non-zero coordinates; any query to an unallocated coordinate immediately returns zero.
---
[03:38](https://www.youtube.com/watch?v=xnez6tloNSQ&t=218s) GraphBLAS and Linear Algebra Duality
Professor Tim Davis takes over to present GraphBLAS, a community effort spanning academia, government laboratories, MIT Lincoln Laboratory, IBM, and Intel. The cornerstone of the project is an observation connecting graph algorithms directly to linear algebra. By decoupling standard linear algebra from hard-coded arithmetic, matrix operations can be generalized over algebraic structures known as semirings. Instead of standard floating-point addition and multiplication, one can substitute customized operators: replacing addition with a minimum operator ($\min$) and multiplication with addition ($+$) turns a standard matrix multiplication into a shortest path computation like the Bellman-Ford algorithm or a step in a minimum spanning tree. Davis points out that while depth-first search remains tricky to reformulate, numerous graph problems map cleanly: “The beauty of this is that then you get all of the beautiful power and expressiveness of linear algebra and and you get the same time complexity as well.”
```mermaid flowchart TD accTitle: Semiring Duality in GraphBLAS accDescr: Standard matrix operations mapped to graph algorithms via custom semirings. subgraph Standard["Standard Linear Algebra"] S1["Multiply: x * y"] S2["Add: sum(products)"] end subgraph Semiring["GraphBLAS Semirings"] B1["Boolean: AND / OR (BFS Frontier)"] MP["Min-Plus: + / min (Shortest Path)"] end Standard -->|"Operator replacement"| Semiring ```
Davis demonstrates this through breadth-first search (BFS). Standard procedural BFS algorithms traverse an active frontier level by level, requiring nested loops that iterate over nodes, inspect outgoing edges, check visited sets, and append unseen targets. Under GraphBLAS, this entire frontier expansion collapses into a sparse matrix-vector multiplication over a boolean semiring, where the multiply operator becomes logical `AND`, the addition operator becomes logical `OR`, and the additive identity zero is boolean `false`. In a min-plus semiring, the zero value is positive infinity ($\infty$). In matrix-vector multiplication, unvisited nodes are selected by applying a mask—a vectorized filter that acts as a bulk `if` condition to exclude already discovered nodes in a single sweep.
- **GraphBLAS consortium**: Developed collaboratively across industry leaders and research institutions including MIT Lincoln Laboratory, IBM, Intel, and Texas A&M University. - **Semiring transformations**: - **Boolean semiring**: Multiplier is `AND`, adder is `OR`, identity element is `false` (ideal for reachability and BFS). - **Min-plus semiring**: Multiplier is `+`, adder is `min`, identity element is $+\infty$ (ideal for Bellman-Ford and shortest paths). - **Masking primitive**: Replaces procedural per-element filtering branches with a vectorized bulk mask that suppresses already-visited vertices.
---
[08:49](https://www.youtube.com/watch?v=xnez6tloNSQ&t=529s) High-Level Abstractions, Lazy Evaluation, and Extensibility
By lifting graph operations from pointer-chasing loops into high-level matrix expressions, GraphBLAS frees users from managing low-level edge lists while giving library authors enormous latitude for optimization. The interface functions much like a “MATLAB for graphs,” offering an expressive, composable language that obeys standard mathematical identities like matrix transposition and associative multiplication. Because matrix internals remain completely opaque behind the C API, GraphBLAS can defer computation through non-blocking mode. Davis humorously describes this lazy evaluation strategy from the library's perspective: “I can say as a user hey oh do this and do this and call this and call this and I'll say oh that's nice thank you very much thank you thank you I'm not gonna do this I'm lazy and then when you're ready to do something I can't be lazy about it it's like oh I better go back and do all this work but see I've I've got a bulk of work now that I can I can do as a group as a large collection.”
This opacity also ensures that backend hardware optimizations do not break caller contracts. If a CUDA-capable GPU is available, the engine can transparently offload calculations to GPU kernels like cuSPARSE without altering the user-facing API. The history of the project spans a decade of algorithmic research, with API design solidifying five years prior to the talk, followed by Davis writing the concrete implementation, which is now packaged directly in mainstream Linux distributions such as Debian and Ubuntu. Beyond performance, GraphBLAS supports full extensibility via user-defined data types and custom operators. Users can construct matrices out of arbitrary payloads—including $4 \times 4$ submatrices or strings—and supply their own functions for addition and multiplication. Davis highlights that adding complex number support required only 500 lines of external user code without needing to modify or recompile GraphBLAS itself.
| GraphBLAS Feature | Procedural Graph Alternative | Practical Advantage | |:--- |:--- |:--- | | **Matrix-Vector Multiply** | Nested loops over vertices and adjacencies | Eliminates pointer chasing; leverages vectorized linear algebra kernels | | **Masking Operation** | Conditional `if` statements inside inner loops | Executes set difference/membership filtering in a bulk pass | | **Non-Blocking Mode** | Immediate sequential step execution | Defers evaluation to fuse operations and optimize execution order | | **Opaque Data Structures** | Exposed node arrays and edge pointer structures | Allows swapping CPU routines for cuSPARSE or distributed engines seamlessly | | **User-Defined Types** | Hardcoded node weight fields in C structs | Supports custom payloads (e.g., matrices, strings, complex numbers) without recompiling |
[12:12](https://www.youtube.com/watch?v=xnez6tloNSQ&t=732s) Breadth-First Search as Linear Algebra
Tim Davis walks through a complete breadth-first search (BFS) implementation using SuiteSparse:GraphBLAS. Displaying the C code styled with Vim syntax highlighting, Davis notes that while it is written in valid C, its high-level mathematical structure means “it almost no longer looks like C.” The routine accepts a graph adjacency matrix and a source node, returning a sparse vector containing the discovery levels of all reachable nodes. Davis emphasizes that this formulation completely eliminates traditional graph traversal boilerplate: “There's just three things to do there's no chasing of nodes or edges in here at all there's no loop that says for every node do this for every neighborhood do this.”
```mermaid flowchart TD accTitle: Linear Algebraic Breadth-First Search Step accDescr: Matrix-vector multiplication and masked assignment forming a single BFS level step. subgraph BFS_Step ["BFS Level Traversal"] direction TB Q["Frontier Vector q<br>(current level nodes)"] --> SpMV["Matrix-Vector Multiply<br>q * A = t (candidate neighbors)"] SpMV --> Mask["Mask with Inverted Visited Vector ¬v"] Mask --> V["Level Vector v<br>(assign levels, filter seen)"] end ```
The algorithm operates on a binary adjacency matrix where columns represent adjacency lists (for example, column 4 has non-zero entries at rows 1 and 3, reflecting edges to nodes 1 and 3). The procedure steps through state vectors rather than visiting individual pointers:
- The vector `q` represents the frontier (nodes at the current level), initialized with `true` at the source node. - A sparse result vector `v` stores discovered level numbers. - A masked assignment updates levels in `v` proportional only to the number of non-zeros in the mask, bypassing any $O(n)$ full-scan penalty. - A matrix-vector multiplication multiplies the frontier vector `q` by the adjacency matrix `A` to yield candidate neighbors `t`. - Applying the inverted visited vector `v` as a mask filters out previously visited nodes (such as node 4 after the initial step) in a single operation. - The process repeats level by level until the frontier produces no unvisited neighbors, leaving the vector empty and terminating the search.
[15:24](https://www.youtube.com/watch?v=xnez6tloNSQ&t=924s) Semirings, GraphBLAS Operations, and Masking
Davis contrasts the flexibility of GraphBLAS with standard numerical computing environments like MATLAB. Having authored MATLAB's internal sparse matrix multiplication routines and the backslash (`\`) operator for The MathWorks, Davis explains that while MATLAB supports four built-in data-type combinations for matrix multiplication, GraphBLAS natively supports 960 semirings—and up to 1.3 million variants when considering typecasting across built-in types. Users can define custom types, monoids, semirings, and accumulator operators, such as recording a parent pointer during a traversal step.
Beyond basic matrix-matrix multiplication, GraphBLAS supports element-wise addition (graph union), element-wise multiplication (graph intersection via MATLAB's `.*` equivalent), reductions, unary transforms, and transpositions. All internal objects—matrices, vectors, semirings, monoids, and descriptors—are fully opaque. This encapsulation allows Davis and the committee to introduce new capabilities (such as descriptors modifying input/output transposition or mask inversion) without breaking existing APIs.
Internally, GraphBLAS represents matrices in Compressed Sparse Column (CSC) format. Davis highlights how the accumulator and mask act as a bulk conditional check across entire graph structures: “Oh but there's a mask that says oh wait no no don't touch those entries only touch these because that's the bulk if that says this is important that I don't do stuff I've already done or only want to change certain parts and that mask can be very sparse.” Because operations can be masked and lazily evaluated, computing a single scalar value out of a matrix multiplication avoids evaluating the whole product, collapsing an apparently $O(n^3)$ operation into constant or near-constant time.
[18:38](https://www.youtube.com/watch?v=xnez6tloNSQ&t=1118s) Submatrix Assignment, Zombies, and Pending Tuples
Modifying sparse graph structures incrementally is notoriously expensive. To address the problem of submatrix and subgraph assignment—expressed in MATLAB syntax as `C(I,J) = A`—Davis implemented an internal state system to prevent expensive repeated data shifts. In standard representations, writing into an existing sparse matrix one entry at a time requires repeated reallocation and data movement. To overcome this, Davis introduced two structural mechanisms:
- **Zombies**: Entries marked for deletion that remain physically present in the sorted CSC arrays. Because shifting memory on every single edge removal is prohibitive, dead entries are tagged in place. If an algorithm writes back to that location, the zombie returns to life without triggering memory reallocations. Zombies also serve as valid positional placeholders to preserve sorted ordering, allowing binary searches inside adjacency lists to succeed without recompacting the array. - **Pending Tuples**: Newly added edges held in an auxiliary queue rather than being merged immediately into the primary CSC structure, creating an internal hierarchy of data structures.
This design enables both bulk creation and high-performance incremental graph construction. Davis notes that while bulk graph construction in GraphBLAS matches MATLAB's top speed, incremental updates diverge dramatically. Building a large graph piecemeal in MATLAB could take an entire day, whereas GraphBLAS handles it seamlessly. Davis emphasizes: “This sub matrix assignment is a hundred times faster than what MATLAB can can do so it's a very efficient implementation of these graph algorithms.”
Concluding his section, Davis summarizes that GraphBLAS allows arbitrary graph algorithms to be expressed in linear algebraic form, exploiting properties like associativity and distributivity while maintaining performance that meets or exceeds commercial engines. Regarding software quality and packaging, Davis affirms: “The code is already available it's it's highly robust bug-free and I don't say that lightly as far as I know it's bug free I mean I that's what I that's that's what I do i write bug-free code.” The library is distributed across major operating systems, including Debian, Ubuntu, and macOS (via Homebrew), before Davis hands the presentation back to Roi Lipman to show how RedisGraph integrates GraphBLAS.
[22:47](https://www.youtube.com/watch?v=xnez6tloNSQ&t=1367s) Traditional Traversal and the Bottlenecks of Serial Query Execution
Roi Lipman steps through how the previous iteration of RedisGraph, alongside many traditional graph databases, executes a typical query. To illustrate, he selects one of the most common graph query patterns: finding friends of friends for all persons aged over 30. Under the old execution model, the engine builds an iterative plan consisting of an index scan, a first expansion (or traversal), a second expansion, and finally a projection phase where matching records are pushed into the final result set.
Execution proceeds in a strictly depth-first, single-record pipeline. First, the index scan identifies person ID 5 as someone over age 30 and advances that ID to the first expansion. Expanding node 5 identifies friend ID 2, which immediately passes to the next expansion stage to find friends of friends. Inspecting ID 2 yields person ID 9, which is promoted directly to projection. The engine must then backtrack to ID 2 to see if other relationships exist. Finding person ID 1, that result is also sent to projection. Backtracking once more reveals no further friends for ID 2, depleting that branch; backtracking again reveals ID 5 has no other direct friends, which depletes that operator; and finally the engine returns to the index scan to fetch another starting ID and repeat the entire loop.
```mermaid flowchart TD accTitle: Old Serial Graph Execution Plan accDescr: Pipeline of traditional graph traversal showing index scan, expansion steps, and projection with backtracking.
subgraph Pipeline ["Serial Query Execution Plan"] Scan["1. Index Scan<br>(Filter: age > 30)"] Exp1["2. Expansion 1<br>(1st Hop Traversal)"] Exp2["3. Expansion 2<br>(2nd Hop Traversal)"] Proj["4. Projection<br>(Result Set Accumulation)"] end
Scan -->|"Push Node 5"| Exp1 Exp1 -->|"Push Friend 2"| Exp2 Exp2 -->|"Found Friend 9"| Proj Proj -.->|"Backtrack"| Exp2 Exp2 -->|"Found Friend 1"| Proj Exp2 -.->|"Exhausted, backtrack"| Exp1 Exp1 -.->|"Exhausted, backtrack"| Scan Scan -->|"Push next candidate"| Exp1 ```
Lipman points out the fundamental architectural flaws of this model: - The execution model is completely serial and depth-first. - Traversal creates continuous random memory accesses, constantly evicting data from CPU caches: “there's a lot of random memory access so we're all the time in violating the CPU cache”. - Graph exploration happens strictly one individual node at a time rather than in vectorized sets.
[26:05](https://www.youtube.com/watch?v=xnez6tloNSQ&t=1565s) Translating Cypher to Linear Algebra and Optimizing Matrix Chains
To resolve these performance barriers, RedisGraph adopted SuiteSparse:GraphBLAS. Because RedisGraph uses Cypher (openCypher) as its primary query language, the system translates high-level pattern-matching statements directly into linear algebra expressions. For the friend-of-a-friend query filtered by age, the engine models the computation as an age filter diagonal matrix multiplied by the graph’s adjacency (friendship) matrix, which is then multiplied by the friendship matrix once again to represent the second hop. In the provided example, the age filter retains persons 2, 3, 4, and 6, while zeroing out persons 1 and 5 who are younger than 30.
Evaluating this expression brings an important mathematical advantage into play: matrix multiplication is associative. This gives the query planner freedom over evaluation order, allowing it to evaluate either $(A \times B) \times C$ or $A \times (B \times C)$. The optimizer’s goal is to minimize intermediate non-zero values, because “each nonzero values not only takes memory but it also takes CPU time when performing multiplication as we need to consider each of these nonzero values.” Multiplying the friendship matrix by itself first yields 18 intermediate non-zeros. In contrast, applying the age filter matrix first pares the initial frontier down to only 7 non-zeros, slashing both memory overhead and arithmetic operations. The final resulting matrix, dubbed "FOAF" (friend-of-a-friend), shows row 6 pointing directly to nodes 3 and 5 via valid two-hop paths, while rows 1 and 5 remain completely zeroed out because their source entities failed the initial age predicate.
[29:33](https://www.youtube.com/watch?v=xnez6tloNSQ&t=1773s) Variable-Length Path Traversals via Matrix Powers
Lipman presents another query pattern that highlights the expressive power of linear algebra: variable-length path traversal, where the user asks for friends of friends within a range of hops (such as two, three, or four hops away). Lipman notes that “This query is not supported on the old version of RedisGraph as it was not simple to introduce it with the current execution model but in the language of linear algebra this becomes really simple.”
Under linear algebra, exploring variable path lengths translates to raising the adjacency matrix to successive powers corresponding to the hop counts:
$$\text{Paths} = (A^2 + A^3 + A^4) \times \text{Filter}$$
Adding adjacency matrices together merges distinct reachability graphs into a combined graph. In a simplified demonstration computing paths of length two and three (omitting four hops because a fourth hop makes every node in the toy graph reachable), Lipman validates the result for node 6. From node 6, the resulting matrix correctly shows reachability to: - Node 1 in three hops (traversing $6 \to 2 \to 3 \to 1$). - Node 3 in two hops ($6 \to 2 \to 3$). - Node 5 in two hops. - Node 6 itself in three hops via a cycle ($6 \to 2 \to 3 \to 6$).
Beyond path reachability, Lipman emphasizes that matrix operations directly express other foundational graph algorithms, including connected components, shortest paths, and minimum spanning trees.
[31:58](https://www.youtube.com/watch?v=xnez6tloNSQ&t=1918s) Distributed Graphs, Parallelization, and Performance Benchmarks
Graph distribution represents one of the most notoriously difficult problems in graph databases. Lipman explains that representing graphs as matrices recasts the distribution problem into block matrix multiplication. Instead of viewing multiplication strictly as row-by-column dot products, the adjacency matrix is subdivided into discrete sub-blocks. Computing an output block (such as block $C_1$) can be scheduled on an isolated thread or sent to an independent network server, after which the master node collects and aggregates the finished blocks. Furthermore, associativity allows complex query plans with chains of multiplications to evaluate non-dependent matrix pairs concurrently, while the low-level primitive matrix multiplication itself parallelizes naturally across modern multicore hardware.
Lipman shares benchmark results evaluating the new GraphBLAS-backed RedisGraph on a real-world graph containing over 1 million nodes and approximately 3 million edges:
| Operation | Benchmark Description | Execution Time | |:--- |:--- |:--- | | **Massive Insertion** | Bulk importing graph nodes and edges into RedisGraph | ~0.5 seconds | | **Neighbor Discovery** | Finding all immediate neighbors for every node in the graph | 50 milliseconds | | **Edge Node Extraction** | Returning source and destination nodes for every edge | 50 milliseconds | | **Shortest Path** | Running breadth-first search (BFS) from a root to 100 deep target nodes | 1 millisecond |
Regarding the edge retrieval speed, Lipman observes: “if you think about it this is simply just returning the matrix all the information required by this benchmark is found within a single matrix so it becomes really easy and fast to perform”.
[35:02](https://www.youtube.com/watch?v=xnez6tloNSQ&t=2102s) Q&A: Higher-Level Graph Algorithms in GraphBLAS
The presentation transitions to a question-and-answer period with the audience. A network scientist raises a question about out-of-the-box analytical capabilities: while expressing operations through basic linear algebra is mathematically elegant, writing community detection algorithms or finding $k$-cliques purely from low-level matrix primitives would be daunting for end practitioners. He asks what higher-level algorithms are currently available.
Tim Davis steps up to answer, affirming that implementing these algorithms directly in basic algebra would indeed be complex: “Right, it would be, so we're working on that.” Davis outlines several algorithms he has already implemented on top of the GraphBLAS primitives: - Luby's algorithm for finding maximal independent sets. - Triangle counting algorithms to calculate triangle density across graphs. - The $k$-truss algorithm, which filters community clusters by pruning peripheral edges: “I've got a $k$-truss algorithm that says I've got a graph and I want to remove any edge that's not in a triangle so you get clusters of communities... the 4-truss is delete any edge that's not in two triangles so you end up with highly only just the highly connected components of parts of the graph.” - High-performance breadth-first search (BFS).
[36:24](https://www.youtube.com/watch?v=xnez6tloNSQ&t=2184s) Algorithm Expressiveness and the Performance Gap
Tim Davis discusses what it takes to write higher-level graph algorithms on top of GraphBLAS. Existing algorithms, such as betweenness centrality, have already been written by other contributors even before a working implementation was available, taking roughly 50 to 100 lines of GraphBLAS code. The immediate next phase of research is evaluating what algorithms can be expressed, and how their execution speed compares against bespoke code written from scratch by a domain expert.
For triangle counting, Tim tested this trade-off directly. A concise implementation takes roughly four or five lines of GraphBLAS, backed by about a hundred lines of pure C. When Tim pulled out all the stops to write custom, expert-tuned C code from scratch—discarding computations on the fly and counting directly instead of constructing an intermediate matrix and reducing it to a scalar—the bespoke version was only about 20% faster than the GraphBLAS implementation. Tim considers this a major success: while handcrafted code might technically shave off cycles, achieving that marginal gain requires enormous implementation effort.
```mermaid flowchart LR accTitle: Triangle Counting Implementation Comparison accDescr: Contrasts concise GraphBLAS implementation with an expert handwritten C routine.
subgraph GB["GraphBLAS Approach"] GBLines["~4-5 lines GraphBLAS + ~100 lines C"] --> GBPerf["Baseline high performance"] end
subgraph Custom["Handcrafted Expert C"] CCode["Custom memory + inline counting"] --> CPerf["~20% faster runtime"] end
GBPerf -.->|"High developer velocity vs minor speedup"| CPerf ```
- Tim observed: “If it pull out all the stops and exploit everything I can do everything I know to make it go as fast as this expert can make go fast I can beat myself by 20% so that's I bet I'm happy about because of course I can be faster than than a API but I can't write it faster.”
[37:58](https://www.youtube.com/watch?v=xnez6tloNSQ&t=2278s) Community Contributions and Algorithm Repositories
An audience member asks whether there will be a centralized repository or standard library of algorithms—similar to NetworkX in Python—so users do not have to piece together common routines on their own. Tim explains his cautious philosophy toward the core SuiteSparse:GraphBLAS engine: he writes nearly all of the core engine code himself because he is protective of stability and wary of third-party contributions introducing subtle bugs into the fundamental package.
However, Tim strongly supports establishing a public, community-driven collection of high-level algorithms built on top of GraphBLAS (such as PageRank or betweenness centrality). He envisions hosting these in an external space, like a GitHub repository or a Stack Overflow-style forum, where users can share recipes and solutions without requiring Tim to formally verify and harden every line within the core library.
- Tim addressed his development habits: “I write most of so this whole package I wrote myself a lot of my codes I just write myself pick his own I don't know trust of the people to not introduce bugs in my code I don't know I however so including features into graph falls under the hood that that I'm not sure about if I can do that with with the public but having a a suite of algorithms written on top of graph laws that use graph laws that say hey this is yours betweenness centrality hey here's a Google Pagerank hey you know those that would be really cool to to have a a site where those kinds of solutions can be posted.”
[39:47](https://www.youtube.com/watch?v=xnez6tloNSQ&t=2387s) The History and Convergence of GraphBLAS
An audience member asks why applying linear algebra and matrix multiplication to graph problems—concepts taught in introductory Computer Science 101—took so long to be formalized into a unified library. Tim explains that the theoretical foundation has been discussed for more than a decade, citing the foundational SIAM book *Graph Algorithms in the Language of Linear Algebra*. For years, researchers attended dedicated workshops and conferences exploring the mathematical equivalences, but nobody had created a standardized, usable API.
Roughly five years prior, an effort began to turn these theoretical insights into a clean, mathematically closed C specification. The GraphBLAS specification committee—comprising dozens of contributors and a five-person core steering committee—finally published the finalized standard just a year before this talk. Tim notes that previous efforts, such as Sparse BLAS, were designed by numerical analysts focused on finite element matrices and solving linear systems, rather than graph theoreticians working with exotic semirings. GraphBLAS represents the long-awaited convergence of these two separate academic communities.
- Tim noted: “That book is about 10 years old there's a community there's been workshops there's been conferences all without any code feel five years ago they started to create the API like ok this time to actually make this happen because people are doing pieces of it but not we need to now generalize it make these approaches available to the world in a cleanly well-designed mathematically closed API and that just finished a year ago that they finish the API.”
[41:58](https://www.youtube.com/watch?v=xnez6tloNSQ&t=2518s) Handling Node Properties, Indices, and Set Operations in RedisGraph
With the session running slightly past its official scheduled time, an audience member describes an architecture problem: they maintain a directed acyclic graph (non-circular node relationships) alongside a separate collection of node property sets in Redis. Querying descendants while performing set intersections across properties currently requires expanding the graph into numerous redundant sets, which consumes massive amounts of RAM. The attendee asks how RedisGraph handles intersections between graph traversals and set properties, and whether graph structures can directly interact with sets without exhausting memory.
Roi Lipman explains that in RedisGraph, the internal matrices represent only node IDs, keeping structural traversals compact and decoupled from payload data. When queries require filtering on attributes (for example, finding all nodes where `age > 30`), RedisGraph avoids looking up raw sets post-traversal by encoding indices directly as vectors or matrices. A filter query is represented as a boolean vector containing a `1` for every node satisfying the predicate; multiplying this filter vector directly against the graph's adjacency matrix constrains graph traversal strictly to matching nodes in linear algebra space.
```mermaid flowchart LR accTitle: Filtered Graph Traversal via Matrix Multiplication accDescr: Multiplying an index vector by an adjacency matrix restricts traversal to matching nodes.
subgraph Filtering["Index Vector Filtering"] Idx["Index Filter Vector (1 for matching nodes, e.g. age > 30)"] end
subgraph Traversal["Graph Traversal"] Adj["Adjacency / Relation Matrix"] Mult["Matrix-Vector Multiplication"] end
subgraph Result["Output"] Res["Filtered Subgraph Results"] end
Idx --> Mult Adj --> Mult Mult --> Res ```
Tim Davis adds that GraphBLAS supports user-defined types (UDTs), allowing a sparse vector or matrix to store arbitrary node attributes directly within the matrix cells. Currently, the specification requires these UDTs to have a fixed byte size, precluding variable-length strings or dynamic heap allocations. However, the GraphBLAS committee is actively exploring support for complex objects managed by constructors and destructors to allow variable-length attributes directly inside matrices. The session concludes with the moderator thanking Tim Davis and Roi Lipman for their presentation.
- Roi explained the indexing architecture: “And so the idea behind the new version of Redis graph is that indices will simply be either vectors or matrices and then what I can do is simply given some vector which has 1 in it for every node which specified some criteria all I need to do is multiply that vector or matrix by some relation matrix and then I'm only focusing on the nodes which applies to that criteria.” - Tim Davis elaborated on data types: “The only constraint for for my for graph Plaza's that the user defined type is a fixed size for all types so it can't be like a variable length string it can't be some malloc bunch of pointer kind of data structure but that's the next thing that's actually in the next step in graft law is to have the type be any any object that can be current with a constructor destructor kind of kind of thing.”
## Mentioned Roi Lipman, Tim Davis, Redis, Redis Labs, RedisGraph, Texas A&M University, Facebook, GraphBLAS, SuiteSparse:GraphBLAS, MIT Lincoln Laboratory, IBM, Intel, MATLAB, The MathWorks, Debian, Ubuntu, CUDA, cuSPARSE, Cypher, openCypher, Vim, Homebrew, NetworkX, SIAM, Graph Algorithms in the Language of Linear Algebra
[Source](https://www.youtube.com/watch?v=xnez6tloNSQ)