---
title: 'Kuzu GDBMS: Recursive & Vector Search'
url: https://www.emergentmind.com/topics/kuzu-gdbms
type: topic
---

# Kuzu GDBMS: Recursive & Vector Search

Searching arXiv for recent papers on Kuzu GDBMS and closely related system work.
Kuzu GDBMS is a **columnar, disk-based, vectorized, pull-based GDBMS** that has been presented as a substrate for two technically distinct but closely related lines of work: robust multi-core execution of **recursive path queries** and **native vector indexing** for mixed graph/vector workloads [2508.19379]. In the recursive setting, Kuzu is used to study how recursive clauses scale on modern multi-core machines when the number of source nodes and the density of intermediate frontiers vary substantially across queries and datasets. In the vector setting, Kuzu is extended with **NaviX**, a native HNSW-based index that supports **predicate-agnostic filtered kNN search** over arbitrary subsets produced by graph or relational subqueries [2506.23397]. Taken together, these works position Kuzu as a research vehicle for integrating disk-based graph storage, morsel-driven execution, recursive traversal, and vector search within one DBMS architecture.

## 1. System profile and storage-execution model

Kuzu is described as a **columnar, disk-based, vectorized, pull-based GDBMS** that already uses **morsel-driven parallelism** [2508.19379]. In the recursive-query work, the storage layer is exposed through a **Graph** interface that provides neighbor scans through the buffer manager over **disk-based CSR adjacency lists**. In the vector-index work, the same DBMS substrate is reused for vector search: NaviX uses **disk-based CSR relationship storage** for adjacency lists, the **buffer manager** for lower-layer graph and vector accesses, and a small **upper-level graph** kept in memory [2506.23397].

This architectural profile matters because both recursive traversal and vector search are implemented as extensions of the existing engine rather than as external subsystems. The NaviX paper explicitly identifies the practical benefits of this arrangement as **persistent graph storage**, **buffer manager caching**, **query planner integration**, and **automatic parallelism** [2506.23397]. A plausible implication is that Kuzu’s research significance lies less in any single operator than in the fact that the same disk-based execution environment can host heterogeneous graph workloads without requiring a separate specialized engine.

## 2. Recursive path queries and the IFE execution model

In Kuzu, recursive clauses are executed through an **IFE (iterative frontier extensions)** subroutine [2508.19379]. Operationally, for each source node, Kuzu repeatedly expands the current frontier by scanning adjacency lists and building the next frontier until convergence. The serial IFE basis used in the paper is:

```latex
\[
\textbf{for } src \in \text{srcNodes:} \quad
nextFrontier.setActive(src) \quad
\textbf{while } curFrontier \neq \emptyset: \quad
\;\; \text{swapCurNextFrontiers()} \quad
\;\; \textbf{for } node \in graph.nodes(): \quad
\;\;\;\; \textbf{if } curFrontier.isActive(node): \quad
\;\;\;\;\;\; \textbf{for } nbr \in node.scanFwd(): \quad
\;\;\;\;\;\;\;\; \textbf{if } edgeCompute(node,nbr): \quad
\;\;\;\;\;\;\;\;\;\; nextFrontier.setActive(nbr) \quad
curFrontier.reset() \quad
outputResults()
\]
```

The paper’s formalization of recursive work is the **IFE source morsel**, defined as

```latex
\[
\text{SourceMorsel} =
\big(\text{currentFrontier}, \text{nextFrontier}, \text{curIter}, \text{phase}, \text{auxState}\big)
\]
```

with $\text{phase}\in\{\text{FRONTIER\_EXTENSION}, \text{OUTPUT}\}$ [2508.19379]. This definition is significant because it shows that frontier expansion and output production are treated as phases of one physical operator rather than independent operators. In implementation terms, the generic IFE physical operator comprises a **MorselDispatcher**, the **Graph** interface, **EdgeCompute**, and a **DestinationNodeMask** that tracks which destination nodes should be reported in the output phase [2508.19379].

Kuzu’s frontier management is also explicitly engineered. The implementation uses a **dense frontier** representation, plus a sparse frontier when the next frontier is very small, defined as **less than one-eighth of the graph**. For actual path output, parent edges are stored in a compact shared structure consisting of a dense array of pointers plus thread-local memory buffers, with **CAS** used to install parent links. For shortest-path-length-only workloads, Kuzu uses a dense length array and a global visited array; the paper notes that the length array uses **1 byte per node** in the implementation because the datasets’ path lengths fit comfortably [2508.19379].

## 3. Morsel dispatching as the central abstraction for recursive parallelism

The recursive-query paper reframes parallel recursive execution as a problem of **morsel dispatching policies**, namely policies that decide what unit of recursive work is assigned to a thread [2508.19379]. Under this view, prior approaches are not unrelated techniques but points in a common design space distinguished by the granularity of the morsel.

| Policy | Morsel type | Characteristic regime |
|---|---|---|
| **1T1S** | source morsel | standard GDBMS style |
| **nT1S** | frontier morsel | few-source workloads |
| **nTkS** | frontier morsels from \(k\) active sources | hybrid, robust |
| **nTkMS** | frontier morsels from multi-source morsels | enough sources to fill 64 lanes |

In **1T1S (1-thread-to-1-source)**, each morsel is a complete recursive execution from one source node. This is identified as the standard GDBMS style used by **Kuzu/Neo4j-like systems**. Its main advantage is that one thread owns one recursive execution, so the recursive state can use simple, non-synchronized structures. Its weakness is poor scalability when there are only a few sources, because there are not enough source morsels to keep all threads busy [2508.19379].

In **nT1S (n-threads-to-1-source)**, each morsel is a chunk of the active frontier from one source’s current BFS level. This is associated with graph analytics systems such as **Ligra** and **Pregel**. It improves on 1T1S when source counts are small because threads can cooperate within one source traversal, but it remains limited by **frontier sparsity**: when a frontier is small, the available parallelism is also small [2508.19379].

Kuzu’s principal proposal is the hybrid **nTkS** policy, formally **n-threads-to-k-sources**, with $k \ge 1$ controlling how many source morsels may be active concurrently. Multiple source-level recursive executions remain alive at once, and each active source’s frontier is still split into frontier morsels. The paper explicitly describes nTkS as **“sticky”**: a worker that gets a source morsel keeps working on it, repeatedly grabbing frontier morsels from that same source until the frontier is exhausted or the source finishes [2508.19379].

The significance of nTkS is its workload-adaptive behavior. If there are **few sources**, it behaves like nT1S; if there are **many sources**, it behaves more like 1T1S, but can still let threads help on another source when one source’s frontier becomes sparse or finishes. This suggests that Kuzu’s recursive execution model is designed around a dynamic mixture of **intra-source** and **inter-source** parallelism rather than a fixed commitment to either source-level or frontier-level execution [2508.19379].

## 4. Multi-source morsels, memory costs, and robustness results

The same dispatching framework is used to reinterpret **multi-source BFS (MS-BFS)** as another morsel policy. In Kuzu’s formulation, MS-BFS packs multiple source traversals together and evaluates them simultaneously using **64-bit “lanes”**. The corresponding policy is **nTkMS**, meaning **n-threads-to-k-multi-source nodes**: instead of launching single-source morsels, Kuzu launches morsels that each contain up to **64 sources**, and threads grab frontier morsels from these packed morsels [2508.19379].

The representation is precise. Each graph vertex stores a **64-bit active-state vector**, one bit per lane. If a vertex $u$ is active in multiple traversals, Kuzu scans its neighbors once and applies the edge computation to all active lanes. For multi-source shortest path/path queries, the implementation uses **two frontiers (current and next), each 64-bit per node**, **one visited structure of 64 bits per node**, and **per-source path/parent state when actual paths are requested**. This yields a base footprint of **24 bytes per node per multi-source morsel** for frontier/visited state alone [2508.19379].

The paper further reports concrete per-node memory costs for nTkMS in Kuzu:

| Workload state | Reported memory |
|---|---|
| frontier/visited only | **24 bytes per node** |
| path-length-only multi-source data total | **88 bytes per node** |
| actual-path storage | **536 bytes per node** |

These figures matter because the gains of multi-source packing are conditional rather than universal. When enough lanes are filled, MS-BFS can improve performance by roughly **1.4x–4.4x** over nTkS, because shared scans and bitwise updates amortize overhead. With **fewer than 32 sources**, however, the packing and bookkeeping overhead usually outweighs scan reduction, so **nTkMS becomes slower than nTkS**. The paper also identifies output type as decisive: for **path-returning workloads**, memory usage can become prohibitive; on **Graph500-28**, path-returning multi-source runs ran out of memory once the source count reached **128** [2508.19379].

The broader experimental findings establish Kuzu’s hybrid policies as robustness mechanisms rather than isolated optimizations. On **1-source workloads**, **Kuzu-1T1S and Neo4j do not scale with more threads**, whereas **Kuzu-nT1S and Ligra do**; **Kuzu-nTkS closely matches Kuzu-nT1S** in this regime. On **8-source workloads**, **Kuzu-1T1S** flattens after 8 threads, **Kuzu-nT1S** remains limited by frontier sparsity, and **Kuzu-nTkS** often improves absolute runtime by about **2x** over nT1S on weaker datasets. On **64-source workloads**, **Kuzu-1T1S** no longer flattens and can sometimes outperform nT1S, but **Kuzu-nTkS** remains consistently strong and often the best or among the best. The paper also reports **CPU utilization metrics** that track these speedups: 1T1S has very low utilization on low-source workloads, nT1S can still underutilize cores when frontiers are sparse, and nTkS usually keeps more cores active [2508.19379].

One dataset-specific result is emphasized: **Spotify** has a very high average degree, which creates dense frontiers and high cache locality. In that case, increasing $k$ can stop helping and can even hurt due to reduced cache locality, so the paper concludes that the **optimal \(k\) depends on graph density** [2508.19379]. This directly counters any misconception that a larger concurrency parameter is uniformly beneficial.

## 5. Native vector indexing: NaviX inside Kuzu

Kuzu’s second major systems extension in the supplied literature is **NaviX**, a **native vector index for graph DBMSs** designed to support **predicate-agnostic filtered vector search queries** [2506.23397]. The target query pattern is a mixed workload in which a graph or relational subquery first produces a subset $S$ of nodes, and then the system searches for the $k$ nearest neighbors of a query vector $v_Q$ **only inside that subset**. The paper defines this as

```latex
\[
\text{kNN of } v_Q \text{ over an arbitrary subset } S \subseteq V
\]
```

where $S$ is determined by an ad-hoc selection sub-query $Q_S$ [2506.23397].

NaviX is built on **HNSW (Hierarchical Navigable Small World graphs)**. The implementation in Kuzu is a **2-level HNSW implementation** with a lower-level graph $G_L$ containing all nodes and most edges and an upper-level graph $G_U$ used for entry routing. The implementation uses a **sampling ratio** $s = 5\%$. On **Wiki**, the paper reports that $G_U \approx 200$ MB, the vectors are approximately **63 GB**, and the lower-level graph is approximately **7.8 GB** [2506.23397].

The search model is explicitly **prefiltering**. Kuzu first evaluates the selection subquery $Q_S$, computes the subset $S$, stores $S$ in a **node semimask**, and passes that semimask to the HNSW search operator. The paper stresses that **filtering happens once before vector search**; no filtering is performed inside the graph traversal itself. Instead, the search operator uses the semimask to decide which nodes are eligible [2506.23397]. A representative query pattern is:

```sql
MATCH (a:Person)<-[m:Mentions]-(b:Chunk)
WHERE a.name = "Alice"
PROJECT GRAPH AliceChunks(b);
CALL QUERY_HNSW_INDEX(AliceChunks, 'ChunkHNSWIndex', k=100, q=[...])
RETURN b, _rank
```

Index creation is likewise integrated into the DBMS interface:

```sql
CALL CREATE_HNSW_INDEX('ChunksHNSWIndex', 'Chunks', 'embedding', M_U)
```

NaviX’s principal algorithmic contribution is **adaptive-local** search. The paper studies a design space of fixed heuristics—**onehop-a**, **onehop-s**, **blind**, and **directed**—and then introduces adaptive-global and adaptive-local selection mechanisms [2506.23397]. The local adaptation is based on **local selectivity**,

```latex
\[
\sigma_l = \frac{|S(\text{nbrs}(c_{\min}))|}{|\text{nbrs}(c_{\min})|}
\]
```

which measures what fraction of the current candidate’s neighbors are selected. Crucially, the paper states that this does **not** involve new filtering or distance computation; it only checks the bits of candidate neighbors in the Kuzu node semimask [2506.23397].

The HNSW convergence criterion used by NaviX is the standard condition

```latex
\[
d(v_q, c_{\min}) > d(v_q, r_{\max})
\]
```

where $c_{\min}$ is the current best candidate from the min-priority queue and $r_{\max}$ is the current farthest result in the max-priority queue [2506.23397]. In engineering terms, Kuzu further adds **in-buffer-manager distance computation**: instead of copying vector data from buffer frames into operator-local memory, the system pins the frame, ensures that it is loaded, executes the distance function directly on the data in the buffer manager frame, and then unpins the frame. The paper reports that this optimization can improve vector search latency by up to **1.6x**, and it uses **SimSIMD** for SIMD-accelerated distance computation [2506.23397].

## 6. Performance profile, limitations, and relation to adjacent GDBMS research

The NaviX results characterize Kuzu’s vector extension as robust across changing selectivity and correlation regimes rather than optimized for one narrow case. Among fixed heuristics, **onehop-s** is best at high selectivity, **directed** is best in medium selectivity ranges and is often up to **2x faster** than blind, and **blind** wins at very low selectivity. **Adaptive-local** is usually similar to **adaptive-global** on uncorrelated workloads but better on correlated workloads; the paper reports cases where adaptive-local is up to **1.7x faster** than adaptive-global, including a negatively correlated benchmark at **5% selectivity** where adaptive-global took **69.13 ms** and NaviX took **40.67 ms** [2506.23397].

The comparative evaluations are equally nuanced. Against postfiltering systems such as **PGVectorScale** and **VBase**, NaviX is reported as more robust as selectivity decreases; one reported scenario shows **PGVectorScale** degrading from about **10 ms** to **334 ms**, whereas **NaviX** degrades from about **8 ms** to **53 ms**. On **Wiki**, one cited comparison gives **NaviX: 18.28 ms** versus **Weaviate: 164.19 ms**. In disk-based experiments, pure cold NaviX is slower than **DiskANN** due to vector I/O, but quantizing and caching vectors closes the gap, and with a small amount of adjacency-list caching NaviX can **outperform DiskANN**. The paper also notes an underlying storage tradeoff: adjacency list access takes **two I/Os in Kuzu**—metadata plus actual list—whereas DiskANN can do a single direct I/O per page [2506.23397]. This directly addresses a possible misconception that integrating ANN search into a DBMS is invariably superior on pure ANN-only workloads; the paper instead presents the integration benefits and the storage-level costs side by side.

A broader systems context is provided by spatial reachability work such as **GeoReach**, which was implemented in **Neo4j** rather than Kuzu but is discussed in terms of relevance to a modern GDBMS like Kuzu [1603.05355]. GeoReach augments graph vertices with **light-weight spatial reachability summaries**—**B-Vertex**, **R-Vertex**, and **G-Vertex**—to support **pruned graph traversal** for **Reachability Query with Spatial Range Predicate**. The supplied discussion does not claim that Kuzu implements GeoReach. Instead, it states that GeoReach’s ideas are relevant to Kuzu in three ways: **vertex-level summaries for pruning**, **multi-resolution spatial summaries**, and **runtime pruning during recursive traversal** [1603.05355]. This suggests a wider research pattern around Kuzu: the system is being used not only to optimize raw traversal or vector search, but also to explore how auxiliary graph-aware metadata can be integrated into recursive or filtered query execution.

Within that pattern, Kuzu’s role is best understood as a DBMS testbed in which different graph-native execution strategies can be compared under one storage and scheduling model. The recursive-query paper concludes that recursive-query parallelism should be understood as a **morsel dispatching problem** over different granularities of recursive work, with **nTkS** proposed as a robust default and **nTkMS** treated as a conditional optimization. The vector-index paper concludes that **native vector indexing inside a graph DBMS is feasible and effective**, particularly when arbitrary predicates, joins, and graph structure must be combined with ANN search [2508.19379][2506.23397].

Source: https://www.emergentmind.com/topics/kuzu-gdbms