Kuzu GDBMS: Recursive & Vector Search

• Kuzu GDBMS is a columnar, disk-based, vectorized, pull-based graph DBMS that combines disk-resident storage with vectorized execution to support heterogeneous workloads.
• It employs agile morsel dispatching policies (nTkS and nTkMS) to balance intra-source and inter-source parallelism for robust recursive path query execution.
• It extends functionality with NaviX—a native HNSW-based index—to enable predicate-agnostic filtered kNN search over subsets derived from graph or relational subqueries.

Searching arXiv for 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 (Chakraborty et al., 26 Aug 2025). 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 (Sehgal et al., 29 Jun 2025). 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 (Chakraborty et al., 26 Aug 2025). 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 (Sehgal et al., 29 Jun 2025).

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 (Sehgal et al., 29 Jun 2025). 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 (Chakraborty et al., 26 Aug 2025). 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:

$k \ge 1$0

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

$k \ge 1$1

with $$\text{phase}\in\{\text{FRONTIER\_EXTENSION}, \text{OUTPUT}\}$$ (Chakraborty et al., 26 Aug 2025). 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 (Chakraborty et al., 26 Aug 2025).

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 (Chakraborty et al., 26 Aug 2025).

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 (Chakraborty et al., 26 Aug 2025). 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 (Chakraborty et al., 26 Aug 2025).

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 (Chakraborty et al., 26 Aug 2025).

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 (Chakraborty et al., 26 Aug 2025).

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 (Chakraborty et al., 26 Aug 2025).

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 (Chakraborty et al., 26 Aug 2025).

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 (Chakraborty et al., 26 Aug 2025).

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 (Chakraborty et al., 26 Aug 2025).

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 (Chakraborty et al., 26 Aug 2025).

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 (Chakraborty et al., 26 Aug 2025). 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 (Sehgal et al., 29 Jun 2025). 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

$k \ge 1$2

where $S$ is determined by an ad-hoc selection sub-query $k$0 (Sehgal et al., 29 Jun 2025).

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 $k$1 containing all nodes and most edges and an upper-level graph $k$2 used for entry routing. The implementation uses a sampling ratio $k$3. On Wiki, the paper reports that $k$4 MB, the vectors are approximately 63 GB, and the lower-level graph is approximately 7.8 GB (Sehgal et al., 29 Jun 2025).

The search model is explicitly prefiltering. Kuzu first evaluates the selection subquery $k$5, computes the subset $k$6, stores $k$7 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 (Sehgal et al., 29 Jun 2025). A representative query pattern is:

$k \ge 1$3

Index creation is likewise integrated into the DBMS interface:

$k \ge 1$4

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 (Sehgal et al., 29 Jun 2025). The local adaptation is based on local selectivity,

$k \ge 1$5

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 (Sehgal et al., 29 Jun 2025).

The HNSW convergence criterion used by NaviX is the standard condition

$k \ge 1$6

where $k$8 is the current best candidate from the min-priority queue and $k$9 is the current farthest result in the max-priority queue (Sehgal et al., 29 Jun 2025). 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 (Sehgal et al., 29 Jun 2025).

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 (Sehgal et al., 29 Jun 2025).

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 (Sehgal et al., 29 Jun 2025). 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 (Sun et al., 2016). 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 (Sun et al., 2016). 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 (Chakraborty et al., 26 Aug 2025, Sehgal et al., 29 Jun 2025).