arXiv CSopen access

To GPU or Not to GPU: Vector Search in Relational Engines

arXiv:2605.15957v1 [cs.DB] 15 May 2026

To GPU or Not to GPU: Vector Search in Relational Engines Vasilis Mageirakos

Joel André

Marko Kabić

ETH Zürich, Switzerland [email protected]

ETH Zürich, Switzerland [email protected]

ETH Zürich, Switzerland [email protected]

Bowen Wu

Yannis Chronis

Gustavo Alonso

ETH Zürich, Switzerland [email protected]

ETH Zürich, Switzerland [email protected]

ETH Zürich, Switzerland [email protected]

ABSTRACT

1

Vector search (VS) is now available in most database engines. However, while vector search is a common feature in AI/ML/LLMs where the dominant computing platforms are GPUs, existing database engines operate on CPUs even when implementing vector search. This raises the question of whether integrating vector processing on GPUs as part of the engine would be a better design. In this paper, we explore this question in detail. First, we extend the TPC-H benchmark with vector data (from text and images) and propose a number of representative SQL+VS queries. Second, we develop a modular execution engine that can run SQL+VS queries across CPU and GPU. Third, we perform extensive experiments on a number of deployments: running the SQL+VS queries across CPU and/or GPU, with data residing in CPU or GPU memory, with existing indices and novel, optimized versions, as well as across different GPUs and interconnects (PCIe, NVLink). The results provide actionable and counter-intuitive insights on how to run such queries over CPUs and GPUs. For instance, the relational components benefit much more from running on the GPU than the vector search part. In addition, when the vector search involves moving data and indexes, using the GPU is not the best option, even with fast interconnects. Thus, we develop an alternative organization of vector index and embeddings that reduces the size of the index, making GPU-based vector search more competitive. With these improvements, the final result is that both the relational and vector search components are faster on the GPU, particularly on fast interconnects, in contrast with the architecture used in existing engines.

Vector databases offer nearest-neighbor and filtered vector search capabilities, many with GPU-accelerated index construction and query serving [34, 48, 49]. These capabilities are being subsumed by relational database systems [41] by integrating vector search (VS) as a standard operator, which has become a common feature in most engines [6, 10, 16, 33, 42, 46, 50]. This integration enables vector search over embeddings to be combined with the expressiveness of SQL. Vector search in relational database systems runs on CPUs, since existing engines typically do not use GPUs. This difference in hardware support is important to study, as relational workloads can run significantly faster on GPUs [14, 26, 51, 52, 55], by using modern interconnects such as NVLink [15, 21], while vector search itself is already routinely run on GPUs in ML systems [13, 48]. Vector search (VS) engines, such as FAISS [8] and cuVS [37], identify data movement as the primary bottleneck: transferring embeddings and index structures across the PCIe bus accounts for the majority of end-to-end runtime, exceeding 90% of query time for large indexes [20]. To mitigate this, VS engines either keep index data resident on the GPU [8, 32, 53], overlap data transfers with computation [47], or explore hybrid CPU-GPU tiering [58]. When it comes to vector search, however, database (DB) engines take a different approach: several DB engines use GPUs to accelerate index building, but execute queries on the CPU [10, 33]. Other DB engines do not use GPUs at all in either index creation or query execution [1, 16]. There are several reasons for this. The embedding data is typically orders of magnitude larger than relational data. With 1024-dimensional embeddings, vector data can be one order of magnitude or more larger than the relational dataset. This means keeping full indexes on GPU memory is impractical since that memory is smaller, more expensive, and shared with other analytical operators. Additionally, research on VS engines confirms that interconnect bandwidth limits GPU querying, and that large batch sizes are needed to amortize transfer costs [13]. Database workloads rarely reach those batch sizes and, typically, do not operate on batches of queries. These concerns are reinforced by how database engines currently use VS indexes: the index stores the actual embeddings, moving an index involves moving all the embeddings. In this paper, we explore the use of heterogeneous CPU-GPU architectures in the context of running analytical SQL+VS queries combining relational and vector search operators. We aim to empirically answer three central questions: a) What are the performance characteristics and requirements of analytical SQL+VS queries b) Does using a GPU accelerate such queries, and c) How should the vector indices and query execution be designed to maximize performance?

PVLDB Reference Format: Vasilis Mageirakos, Joel André, Marko Kabić, Bowen Wu, Yannis Chronis, and Gustavo Alonso. To GPU or Not to GPU: Vector Search in Relational Engines. PVLDB, 14(1): XXX-XXX, 2020. doi:XX.XX/XXX.XX PVLDB Artifact Availability: The source code, data, and/or other artifacts have been made available at https://github.com/mageirakos/vec-h.

This work is licensed under the Creative Commons BY-NC-ND 4.0 International License. Visit https://creativecommons.org/licenses/by-nc-nd/4.0/ to view a copy of this license. For any use beyond those covered by this license, obtain permission by emailing [email protected]. Copyright is held by the owner/author(s). Publication rights licensed to the VLDB Endowment. Proceedings of the VLDB Endowment, Vol. 14, No. 1 ISSN 2150-8097. doi:XX.XX/XXX.XX

INTRODUCTION

2

These are non-trivial questions, as they involve elements that interact with each other in non-intuitive ways: architectural regarding the interconnects, engine design regarding where the queries run, and data structure design regarding the way the indexes are constructed. To answer these questions, we propose a novel analytical vector search benchmark and develop a system to seamlessly run them across CPU-GPU. The benchmark, called Vec-H, extends TPC-H with two new tables of real semantic embeddings and eight representative analytical SQL+VS queries spanning five VS integration patterns (inner, left, lateral, anti, semi). The queries explored cannot be expressed in the query languages of pure vector databases (i.e., no SQL support) [34, 48, 49]. For the system, we developed MaxVec, a CPU-GPU execution engine for SQL+VS queries. It extends Maximus [14], an accelerated CPU-GPU query engine for data analytics, with VS operators for exhaustive nearest-neighbor search (ENN) and approximate nearest-neighbor search (ANN) via FAISS/cuVS [8, 37]. Each operator can be placed on a CPU or a GPU independently, and the engine handles index and data movement across devices transparently. To our knowledge, MaxVec is the only open-source engine that supports full SQL+VS on a hybrid CPU-GPU platform. Based on this infrastructure, we perform extensive experiments using existing vector search libraries and algorithms, all of which are available for extension and further experimentation. We run VecH using MaxVec on three hardware configurations with PCIe 5.0, NVLink-C2C, and unified CPU-GPU memory (DGX Spark [30]). The results are a series of important and counterintuitive insights: Regarding CPU vs. GPU execution, we have experimentally tested where to run queries, entirely on the CPU, the GPU, or hybrid. This initial analysis leads to two surprising insights. First, using standard vector search libraries and indexes, GPU execution yields a bigger improvement for relational operators than for vector search. Second, relational operators can be orders of magnitude more expensive than a vector search. Regarding faster interconnects, MaxBench [15] shows that for relational analytics, data transfers account for 67–98% of runtime on PCIe, but on NVLink the interconnect bottleneck disappears and execution becomes GPU bound. Our experiments show that this is not the case for vector search. Even when using NVLink, with current data-owning vector indexes, running vector search on a GPU does not pay off unless the vector index is resident on the GPU. This is because the size of the index is so large, and its transfer incurs per-call setup and CPU-to-GPU index transformation overheads, that the increase in bandwidth is not enough to compensate for the added latency of having the data movement. In terms of the index itself, we show that by separating the actual index (comparatively very small) from the storage of the embeddings (very large), it is possible to move the index to the GPU when needed, making running both the relational and vector search components on the GPU the faster option even when the data for the relational and vector search have to be transferred to the GPU.

RELATED WORK

GPU vector search. GPU-accelerated VS libraries achieve speedups over CPU implementations for both index construction and query execution [20, 32, 47, 58]. FAISS [8] is widely used, supporting CPU and GPU execution on multiple index types. Its GPU backend integrates cuVS, which provides CAGRA [32] and other GPU-optimized indexes. CAGRA, the current GPU graph-based index SOTA, reports 33–77× higher throughput than CPU HNSW at 90–95% recall. For datasets that exceed GPU memory, BANG [47] and RUMMY [58] split data between the GPU and the host. The tradeoff is higher search latency from fetching data over the interconnect during search. VecFlow [53] is the first purpose-built GPU index for filtered search, but supports only categorical label predicates, not arbitrary SQL predicates. Database-integrated vector search. Vector databases such as Milvus [48] support GPU-accelerated VS and filtered vector search (FVS) [7], although filters run on the CPU. They focus on VS and FVS workloads rather than general queries. Several database systems integrate VS with CPU-only query execution [6, 10, 16, 33, 42, 50, 56]. The two closest GPU SQL engines, Theseus [3] and Sirius DB [55], both list vector search as future work. Our work fills this gap with a query engine capable of full SQL+VS (ENN and ANN) on heterogeneous CPU+GPU hardware. Interconnect and data movement. Lutz et al. [21] provide the foundational NVLink-vs-PCIe study for database workloads. More recently, MaxBench [15] extends this to modern hardware (PCIe 5.0, NVLink-C2C) and shows that data transfers account for 67–98% of relational query runtime on PCIe, while NVLink shifts execution to be GPU-bound. A recent GPU VS survey [20] confirms the pattern for vector search on PCIe, where data transfers consume 40-97% of the total latency, but does not extend the analysis to modern hardware. VecFlow-Chamfer [25] uses cache-coherent host-memory access over NVLink-C2C, a hardware capability of NVIDIA’s Grace Hopper Superchip [29], to read from host memory during the final re-ranking step of their pipeline. We study and utilize these hardware capabilities for different workloads and indexes, and characterize which design wins and when, in Section 5. Related benchmarks. Existing benchmarks [4, 17, 59] evaluate standalone nearest-neighbor search or add simple predicate evaluation on embedding metadata. On the database analytics side, TPC-H and TPC-DS [43, 44] are the standard relational benchmarks but do not contain vector search operators. The unique advantage of relational databases with integrated VS support is access to the full relational data model and the expressiveness of SQL. Under existing benchmarks, it is difficult to differentiate database systems from specialized vector databases. The closest to our benchmark are SemBench [19] and Exqutor [18]. SemBench combines SQL with semantic operators, but uses LLM invocations whose “processing overheads dominate total computation costs” [19]. Exqutor targets cardinality estimation for vector predicates on CPU, attaching embedding columns to TPC-H and TPC-DS for a range-based distance filter over the original queries. We instead target execution on heterogeneous CPU/GPU hardware, with Vec-H queries that span multiple VS integration patterns (inner, left, lateral, anti, semi), real semantic embeddings, and two new tables joined to TPC-H.

2

VS@Mid

VS@Start

VS@End

​⋊

SQL

Vector Search

Vector Search Vector Search

Query Query

(Query)

(Data)

SQL

SQL

SQL Data

Data

Figure 2: Vec-H query reference implementations in MaxVec. vice versa. Review counts per product are long-tailed, while image counts are more normally distributed. Since review and image embeddings may originate from models with different dimensions 𝑑𝑟 and 𝑑𝑖 , the total embedding data size is approximated by: Vec_bytes ≈ 𝑆𝐹 × 200,000 × (𝑅 × 𝑑𝑟 + 𝐼 × 𝑑𝑖 ) × 𝑏, where 𝑏 are the bytes used per dimension. The Rel:VS data ratio is the TPC-H data size (∼1 GB per SF) to the embedding data size (Vec_bytes) in gigabytes. It is dependent on the embedding dimensions 𝑑𝑟 and 𝑑𝑖 , the bytes per dimension 𝑏, and the productto-part mapping, which determines 𝑅 and 𝐼 per part. The Amazon Reviews dataset [12] has 48M unique products, and thus enough data to support a Vec-H with SF≈240 (48M parts), after which all 571M reviews and 133M images have been assigned. The scale factor, embedding models, dataset configuration, and Rel:VS we used are listed in Section 5.

Figure 1: Vec-H schema: TPC-H extended with IMAGES and REVIEWS tables, each with an EMBEDDING column.

3

VEC-H BENCHMARK

We design the Vec-H benchmark to study and optimize SQL+VS queries. It targets analytical SQL+VS queries that combine nearestneighbor search with joins, aggregates, and ordering. We extend TPC-H with two tables containing embeddings and eight unique query templates. We treat exact embedding models, dimensionality, and data source as adjustable parameters.

3.1

Dataset

3.2

Data source. Vec-H adds two tables to TPC-H, the REVIEWS and IMAGES, populated with data from the Amazon Reviews dataset [12], which covers 34 product categories of 48M unique products with 571M reviews, and 133M images. Schema and mapping. The extended schema is shown in Figure 1. We establish a one-to-one mapping between TPC-H parts and Amazon products: each P_PARTKEY is randomly assigned a single parent_asin (Amazon’s unique product identifier). All reviews and images of the sampled product are then added to the reviews and images tables and linked to their part via foreign keys, minus those dropped during cleaning (e.g., broken image URLs). Each review is also assigned to a customer by mapping the Amazon user_id to a C_CUSTKEY. If distinct Amazon users exceed the fixed TPC-H customer count for a given scale factor (SF), we assign the reviews randomly to existing C_CUSTKEYs. Thus, we preserve the TPC-H customer cardinality per SF and the part-to-review real world distribution, but not the original distribution of reviews across Amazon users. Once the mapping is fixed, P_PARTKEY acts as the product identifier: REVIEWS and IMAGES join to PART and CUSTOMER. Reviews and images are provided by the Amazon Reviews dataset in their raw form (text, image URLs). We generate one embedding per review and per image using open-source models. Dataset scale. We use the SF-based scaling of TPC-H. At SF=1, the TPC-H dataset is ∼1 GB. For the embeddings, at a given SF, the total data size depends on embedding dimensionality and bytes per dimension. The number of reviews and images is well-approximated as SF × 200,000 × 𝑅 and SF × 200,000 × 𝐼 respectively, where 𝑅≈12 and 𝐼 ≈4 are the average reviews and images per product across all product categories. Products may have reviews and no images or

Logical Vector Search Operator

We define a vector search operator logically as vector_search(query vectors, embedding column, k), where for every query vector the operator finds the 𝑘 closest embeddings. We allow for two inputs in the operator (query vector and embedding data sides). This way, the vector_search operator is binary. It can be used as a similarity join operator [39, 54], operating on a batch of queries, or a simple vector search when the query vector input side has a cardinality of 1. We discuss the design in more detail in Section 4.3.

3.3

Queries

Each Vec-H query directly extends its TPC-H counterpart (Vec-H Q2 extends TPC-H Q2, and so on). Readers familiar with TPC-H can identify the core relational backbone of the query. To connect the VS result to the relational plan, every query introduces at least one additional join. Table 1 summarizes the set of queries, their join types, and the aspect of analytical SQL+VS execution targeted. We classify queries by where the VS operator appears in the execution plan: VS@Start, VS@Mid, or VS@End (Figure 2). These labels reflect data dependencies between the VS and relational subplans. Below we describe the Vec-H queries along with an example business logic of use cases they support. Full SQL definitions and sample result outputs are available in the artifact repository. 3.3.1 VS@Start Queries. In these queries, vector search is the query driver. On the VS operator, the data side is a base table, and the query side is a user-provided query embedding (Figure 2). The top𝑘 result set affects downstream operators of the plan, either by inclusion (inner or semi-join) or exclusion (anti-join). 3

Table 1: Vec-H query summary. Each query extends a TPC-H base with vector search. Join type describes how VS results integrate with the relational plan. Query

TPC-H Base

VS Use Case

Join Type

Key Distinction

VS@Start Q2 Min-cost supplier Q16 Parts/supplier count Q19 Discounted revenue

Image similarity filter Semantic review exclusion Dual VS OR branches

Inner join Anti-join Semi-join, ×2

Join order sensitivity to 𝑘, distance in ORDER BY Exclusion changes GROUP BY aggregate counts Two vector searches on different modalities

VS@Mid Q10 Returned item revenue Q13 Customer distribution Q18 Large volume customer

Review similarity flag Review match count Visual quantity score

Left join Left join Left join

VS annotates matches VS adds new GROUP BY aggregation dimension VS contributes numeric aggregate

VS@End Q11 Important stock Q15 Top supplier

Visual duplicate detection Semantic review ranking

Left join lateral Inner join

Forced execution order, batched per-row VS SQL scopes VS data, symmetric to VS@Start

Q2: Minimum Cost Supplier. TPC-H Q2 finds the minimumcost supplier in a given region for parts of a specific type and size. Vec-H replaces the part type and size predicate with a top-𝑘 image similarity search, selecting the parts whose image is closest to the user query image. The VS returns 𝑘 images each belonging to a unique part. This result is inner-joined to the rest of the plan on p_partkey, with 𝑘 directly controlling the selectivity, acting as an inclusive filter where a larger 𝑘 has more qualifying parts. For a very large 𝑘, an optimizer could theoretically choose to reorder the joins, and run part of the relational subquery first. Q2 also uses the VS distance as a secondary sort key in the ORDER BY. Business logic: Given a query image, find the suppliers which offer the minimum cost for the 𝑘 most visually similar parts. Q16: Parts/Supplier Relationship. The TPC-H Q16 query excludes suppliers whose comment field contains “Customer” and “Complaints”. We substitute the substring matching predicate with vector search, to exclude suppliers associated with the 𝑘 most similar reviews to a query embedding via NOT IN. Unlike Q2’s inclusive filter, Q16 affects downstream operators in the opposite way. Business logic: What is the number of “trustworthy” suppliers for a given part group (brand, type, size). Trustworthiness is defined by excluding suppliers linked to parts with reviews related to a specific complaint, a negative keyword, or a topic of concern. Q19: Discounted Revenue. TPC-H Q19 computes the discounted revenue across three part categories, combined via OR. Vec-H extends the query with two additional VS-defined categories, one matching parts by review similarity and the other by image similarity. Because the branches are combined with OR, the VS results expand the qualifying set. Q19 is the only Vec-H query requiring two simultaneous VS searches across different indices.Business logic: What is the total discounted revenue for parts identified by a traditional brand/container criteria OR a semantic review description OR a visual reference image.

retrieves the global top-𝑘 reviews most similar to a query embedding, with no restriction to returned products or to the Q10 customers. The LEFT JOIN on c_custkey annotates each Q10 output row with an is_in_top_k flag, marking whether that customer happens to appear among the top-𝑘 reviewers. Business logic: Among customers responsible for the most returned-item revenue loss, which ones also authored a review similar to a target complaint? Q13: Customer Distribution. TPC-H Q13 computes the distribution of customers by their number of orders, including customers who have no order record. Vec-H independently retrieves the global top-𝑘 reviews by similarity and LEFT JOINs them to count how many top-𝑘 reviews belong to each customer. Unlike Q10 and Q18, where VS annotates the final output rows, Q13’s LEFT JOIN sits inside the nested subquery, so the VS-derived count propagates through both GROUP BY levels into the output as a second distribution dimension alongside the original order-count distribution. Business logic: Which customer buckets, grouped by order count, concentrate reviews that are most similar to a query embedding? For instance, reviews similar to complaints made by customers with zero orders may signal fraudulent activity. Q18: Large Volume Customer. TPC-H Q18 finds the top-100 customers with the largest-quantity orders. Vec-H LEFT JOINs the top-𝑘 visually similar part images to each line item. A CASE expression sums l_quantity only for line items whose part matches the VS result, producing a similar_qty score per order. The output is re-ranked by similar_qty, surfacing orders that contain the most items visually similar to the user query. Combined with TPC-H Q18’s multi-join relational plan and HAVING subquery, this tests whether a system can handle a heavy relational workload alongside a full VS branch. Business logic: Among customers with the largest orders, how many of their ordered items visually resemble a reference part? Re-rank by this visual match quantity. 3.3.3 VS@End Queries. In these queries, SQL output feeds VS operator inputs (Figure 2). Q11: Important Stock Identification. TPC-H Q11 identifies parts whose total stock value from a given nation exceeds a fraction of the global value. Vec-H uses each high-value part’s image as a per-row query vector to find its nearest visual duplicate via LEFT JOIN LATERAL, excluding self-matches. Here, the query vectors

3.3.2 VS@Mid Queries. In these queries, VS and the SQL subplans are in separate query plan branches. VS can enrich the SQL output via LEFT JOIN but does not filter any rows. Q10: Returned Item Reporting. TPC-H Q10 ranks the top-20 customers by lost revenue from line items those customers returned within a given quarter. Vec-H adds an independent VS branch that 4

4.1

come from the data itself: each part’s own image is used to search for visually similar parts. An optional 𝑘 on the CTE can limit how many high-value parts enter the VS stage, controlling the batch size. We set 𝑘 so that all qualifying rows pass through. Query vectors do not exist until the TPC-H subquery completes, so the SQL plan must run before any VS work can begin. Business logic: Among the highest-value stock parts from a given nation, which have visually near-identical counterparts? Q15: Top Supplier. TPC-H Q15 finds the supplier with the highest quarterly revenue. Vec-H then joins through partsupp and part to collect all reviews for that supplier’s parts, and ranks them by semantic similarity to a query embedding. The INNER JOIN restricts which reviews the VS operator searches, scoping the data side rather than the query side. This is symmetric to VS@Start from the opposite direction: where Q2 uses VS results to filter SQL, Q15 uses SQL joins to restrict VS data. Business logic: For the toprevenue supplier in a given quarter, what are the most relevant reviews (by semantic similarity to a specific concern) for the parts they supply? 3.3.4 Result Quality. Vector search is inherently an approximated operation. Errors, whether originating from the embedding model, the choice of ANN over ENN, or desired value of 𝑘, can propagate through the query plan and affect the final result. The core metric we use for result quality assessment is recall: the fraction of true output rows that appear in the ANN result. We measure recall at the query output level, not at the VS operator level. We treat the result of a query that uses ENN (exhaustive) operator as the ground truth. Q19 requires a query-specific metric, its output is a single SUM(revenue) scalar, so row-level recall collapses to a binary match (100% if the number is exact, 0% otherwise). Therefore we report relative revenue error, rel_err = |rev ANN − rev ENN |/rev ENN , where rev ANN and rev ENN are the aggregate revenue produced by the ANN and ENN runs. Lower error is better, and the metric is scale-free and weights each missed top-𝑘 partkey by the revenue it would have contributed through the downstream lineitem join. We target ≤1% relative error for Q19, and at least 95% recall per-query. Result quality also depends on how 𝑘 interacts with the relational plan. In Q2, Q15, Q18, and Q19 on ANN we have a post-filter execution pattern where a predicate may discard VS results. Thus, we over-sample top-𝑘 ′ , where 𝑘 ′ ensures returning 𝑘 passing rows. On the GPU, the indices in FAISS enforce an upper bound on 𝑘 ′ which the CPU path does not have [13, 24], so if the over-sampling required to achieve a recall target exceeds this limit, the query must fall back to CPU. Q15 is one such case in Vec-H, where the GPU top-k limit is reached, which is noted in Section 5.

4

Maximus Background

Maximus [14] is a query execution engine for heterogeneous environments, originally designed for relational data analytics. Its central idea is operator-level integration, where different execution engines, potentially targeting different hardware such as CPUs, GPUs and FPGAs, can be combined within a single query plan. Maximus allows each operator to be independently assigned to a specific device and backend. This is achieved through a namespace nomenclature of the form device::engine::operator. For example, a filter operation can be executed on the CPU using the Acero engine (cpu::acero::filter), while a hash join in the same plan runs on the GPU using cuDF (gpu::cudf::hash_join). A key feature of Maximus is its ability to automatically orchestrate data movement and format conversion between operators. On CPU, data is represented in Arrow columnar format and executed by the Acero engine. On GPU, data is represented in cuDF format, which also serves as the execution engine for relational operators. Conversions between these formats are implemented lazily and are zero-copy whenever possible. Data transfers across devices (e.g., CPU to GPU) are handled transparently and executed asynchronously to minimize overhead. While this design targets relational processing, extending it to vector similarity search introduces new challenges. Vector search requires handling high-dimensional embeddings, specialized index structures, extending memory pool management, defining the semantics of new vector search operators, integrating compute-intensive kernels, and extending the benchmarking layer to profile index movement and VS operators. Incorporating these elements into the existing operator-level abstraction required substantial extensions across the Maximus architecture.

4.2

Data Formats and Index Management

To support vector embeddings within relational tables, we introduce a new column type, embeddings_type. This type is implemented as a nested list structure, where each tuple contains a vector. On the CPU, this is represented using arrow::ListType, while on the GPU it is implemented using cudf::ListDType. Internally, both representations store all embedding values in a contiguous memory region, enabling efficient access patterns. This design allows us to provide zero-copy interoperability with FAISS by directly exposing the underlying memory buffers as embedding arrays. As a result, embeddings stored in tables can be used for index construction and query evaluation without additional serialization or copying overhead. In addition to native embedding column support, FAISS index structures are integrated as transferable objects in the engine, similar to tables. Indices can reside in CPU or GPU memory. Index transfers use FAISS’s built-in functions. We introduce optimizations (memory pinning, index caching and secondary non-data-owning VS indices with host-data access) to reduce transfer overhead. On the GPU side, we integrate FAISS into the Maximus RMM (RAPIDS Memory Manager) memory pool [38], so that relational data and vector indices are managed under one memory budget with shared CUDA streams and access to pinned memory.

MAXVEC ENGINE

MaxVec extends Maximus [14], a modular query execution engine, to support vector search. The integration incorporates FAISS [8] with both its CPU and GPU (cuVS-enabled [37]) backends as a new execution engine for vector search. This allows relational and vector search operators to be combined within a single query plan with automatic data movement across devices. This section describes the extensions required: new data formats for embeddings, index management, and vector search operators.

4.3

Physical Vector Search Operators

Vector search operators follow the same namespace abstraction, and operate on embeddings in the embeddings_type format. Database 5

or Images). MaxVec supports two modes of vector search indices. In the first mode, the embedding vectors are stored within the index structure itself, which to our knowledge is the approach used by all current DBMS+VS engines. In the second mode, the embedding vectors are decoupled from the index structure and stored separately. We adopt the terms data-owning and non-dataowning vector search indices to refer to these data structures. Data-owning index. The layout of embedding data within the index (row-wise, interleaved, etc.) is chosen by the index. The index also holds an ID in order for MaxVec to have a mapping back to the relational table row. The benefit of such a design is the flexibility to customize the layout for efficient distance computation, with separate optimizations across the CPU and GPU. The downside is a larger index, since the embeddings are part of the index, making it more expensive to move. Non-data-owning index. The index holds only the search data structure, the embeddings_type data remain on the base table and are accessible during search. First, this design eliminates the redundant copy of the embeddings: much like a secondary B+ tree index, the index points into the base table rather than storing the data itself. Since FAISS does not natively support this layout, we patched it to decouple the index structure from the embedding storage. Second, compared to the data-owning design, when the index resides in CPU memory and the vector search operator is scheduled for GPU execution, only the compact search structure (centroids for IVF [40], the graph for CAGRA [32]) must be transferred before execution begins, which is significantly less data than the full embedding set. Then, the GPU fetches only the necessary embeddings from host memory on demand during vector search. We cover how we implement the data transfer in the next section. Vector Index Data Movement optimizations. Moving the index from CPU to GPU is decomposed into i) host to device (HtoD) transfers, ii) per-call HtoD setup, and iii) CPU index to GPU index transformation. To optimize the data movement cost, we implement three optimizations. We describe each mechanism here using index types and interconnects from those experiments as examples, and defer measurements to Sections 5.4 and 5.5. Caching targets component (iii), the CPU index to GPU index transformation. MaxVec transforms the CPU index and caches it so that it can be directly used by the GPU constructor. Without caching, the index would be transformed during the critical path of the index movement for each query. One example of the cached transformations, is embedding layout conversion from a row-major format on the CPU to an interleaved format on the GPU. Another, for graph indices, is the HNSW→CAGRA conversion, required because the index types differ in structure: HNSW (CPU) [23] is a multi-layer graph where the bottom layer (level 0) contains every node and its neighbor list, while CAGRA (GPU) [32] uses a single flat kNN graph. On each transfer, FAISS extracts the HNSW level-0 neighbors into a dense matrix, and converts the ID type to what the cuVS CAGRA constructor expects. Pinning targets component (i), the HtoD transfer time, by removing the host-to-host staging copy that pageable allocations require. Pageable host pages can be swapped by the OS, so it is not safe for the GPU DMA engine to address directly. When a cudaMemcpy is issued, the CUDA driver first copies the bytes into a temporary page-locked staging buffer in host RAM, then DMAs from there to

Figure 3: Vector search operators in MaxVec. Exhaustive (left) and indexed (right, where index may own the data). engines such as DuckDB [35] allow physical operators like hash joins to expose multiple input ports, each of which can be blocking or streaming. We adopt this design in our vector search operators, which have two input ports, one for the query vector side and one for the data side. The data port is always blocking: the full data side must be materialized before search begins, since queries need to identify their nearest neighbors from the entire data side input. Our operators can operate on a single query or a query batch. On CPU, the query port is streaming: query batches are processed as they arrive. On GPU, the query port is blocking. All query-side vectors are accumulated into a single batch so the distance computation runs as one large matrix multiplication rather than many smaller independent vector products. Distance computation between a 𝑁 vector query batch and 𝑀 data vectors of dimension 𝑑 expands to a 𝑁 × 𝑑 × 𝑀 GEMM, so larger batches produce wider GEMM kernels and better utilize GPU compute [28], which is why batching is necessary for higher GPU throughput and utilization for VS. Before execution, data tables and indices can each reside on CPU or GPU. Data movement is handled at execution time, transferring all inputs to the operator’s scheduled target device. The FAISS vector search kernels return raw arrays of the query nearest-neighbor indices and distances. The operator constructs the output table by gathering the corresponding rows from both inputs (query vectors and data) and adding a distance column. Any input column can be projected away on the output, to avoid materializing columns the plan does not use. The same operator serves both single-query vector search and similarity join [54]. Figure 3 illustrates an exhaustive VS operator (left) on a batch of queries, and an indexed VS operator (right) that operates on a single query vector. For each 𝑄_𝑖𝑑, the output contains the 𝑘 = 2 nearest 𝐷_𝑖𝑑 neighbors and, optionally, their 𝐷𝑖𝑠𝑡𝑎𝑛𝑐𝑒, along with other columns from both input sides. When the query side comes from a similarity join (e.g., Vec-H Q11’s LEFT JOIN LATERAL), the batch is produced from the join’s outer relation. 4.3.1 Exhaustive VS Operator. The exhaustive operator computes distances between every query embedding vector and every data vector from the data-side table, i.e., it is an exact nearest neighbor search (100% recall). It uses FAISS’s brute-force search kernels on the embeddings_type columns of CPU/GPU tables. 4.3.2 Indexed VS Operator. The indexed operator uses a FAISS or cuVS index built on the embeddings of base tables (e.g., Reviews 6

Table 2: Hardware configurations.

CPU CPU cores GPU Mem. BW Memory Interconnect IC BW (1-way)

H100-PCIe 5.0

GH200-NVLink

DGX Spark

AMD EPYC 9124 16 H100 NVL 94 GB 4 TB/s (HBM3) 94 GB HBM3 PCIe 5.0 64 GB/s

ARM Neoverse V2 72 H100 96 GB 4 TB/s (HBM3) 96 GB HBM3 NVLink-C2C 450 GB/s

10×X925 + 10×A725 20 GB10 Blackwell 273 GB/s (LPDDR5x) 128 GB unified — —

Table 3: Execution strategies for hybrid SQL+VS queries. Execution

Data on

Transfer

Strategy

VS

Rel

Idx

Emb

Rel

Idx

Emb

Rel

cpu gpu hybrid copy-di copy-i gpu-i

CPU GPU CPU GPU GPU GPU

CPU GPU GPU GPU GPU GPU

H D H H H D

H D H H H H

H D H H H H

— — — copy copy —

— — — copy stream stream

— — copy copy copy copy

H = host, D = device, copy: before execution, stream: read host memory at runtime

the device [11]. Pinning skips this staging copy. Pinned memory is a scarce system resource, so MaxVec pins data selectively, for example index embeddings and base tables that repeatedly cross to the GPU. The pinning optimization is used on PCIe, as NVLink-C2C delivers the same bandwidth on pageable and pinned allocations [9]. Host-residency targets components (i) and (ii). This optimization makes the non-data-owning design efficient by using hardware support. The unified-memory mechanism enabling this access is hardware-dependent. On GH200 (Table 2), the CPU and GPU sit on separate physical memory pools connected by NVLink-C2C. The GPU’s MMU resolves host virtual addresses through the system page table via Address Translation Services (ATS), so the GPU reads host memory directly [27]. For partition-based indices, the per-partition cudaMemcpy calls used to copy embedding data are also eliminated, reducing the per-call HtoD setup count (ii).

5

separate EXPLAIN ANALYZE or profiling runs are used to get additional information (i.e. the relational-to-VS operator time ratio). Measurement Methodology We tune our query execution to achieve at least 95% recall, and report query latency. In all cases and systems, each experiment is repeated 20 times, with the first repetition discarded as a warm-up. Unless otherwise noted, all host-side data (tables, index buffers, intermediate results) resides in non-pinned (pageable) memory. For all vector search queries we use 𝑘=100. Where necessary, we set the post-filter [50] oversampling 𝑘 ′ to 10 × 𝑘, except Q15 which requires up to 500 × 𝑘. This high oversampling exceeds the GPU top-𝑘 cap enforced by FAISS (Section 3.3.4), so Q15 on the GPU has <50% recall. We therefore explicitly analyze Q15 only in the CPU cases that meet the target recall, and report the GPU-achieved performance as a reference. Index types. We cover the two dominant ANN types: partitioned (IVF via FAISS) and graph-based (HNSW on cpu via FAISS, CAGRA on gpu via FAISS/cuVS). The number suffix (e.g. IVF1024) is the partition count. Pgvector has both IVF and HNSW. We use Exhaustive and ENN interchangeably to indicate exhaustive vector search. The approximate ANN cases are labeled by index type. Execution strategies. Table 3 sorts the execution strategies evaluated by where each vector search (VS) or relational (Rel) operator is executed, where the index, embeddings, and relational tables reside at query start (host H or device D), and what crosses the interconnect at run time. cpu is the strategy used in current RDBMS+VS systems: all data resides and query is executed on the host CPU. hybrid runs VS on the CPU and the relational side on the GPU, copying only the relational data to the device. The remaining four strategies run both operators on the GPU. In gpu, all data is pre-resident on the device. copy-di uses a data-owning index that copies both embedding data (d) and index structure (i) per query, along with the relational tables. To the best of our knowledge, data-owning indexes are the default in every DBMS with integrated vector search. copy-i and gpu-i use a non-owning index: only the index structure is copied to or kept on the GPU, while embedding rows stream from the host on demand, as the VS operator accesses them. copy-i copies the index per query, gpu-i keeps it resident on GPU memory. Time breakdown. We report runtime for each configuration in bar plots, queries are ordered following their Vec-H taxonomy (Section 3): VS@Start (Q2, Q16, Q19), VS@Mid (Q10, Q13, Q18), VS@End (Q11, Q15). Unless stated otherwise, the label on the rightmost (gpu) bar of each per-query plot is the per-system CPU→GPU speedup for the MaxVec engine. Each bar sums four components

EXPERIMENTAL ANALYSIS

Using the Vec-H benchmark and the MaxVec engine, we present an empirical analysis of SQL+VS queries on different engines, hardware, interconnects, execution strategies, index types and designs.

5.1

Experimental Setup

Hardware & Software We run three hardware configurations (Table 2) spanning PCIe 5.0, NVLink-C2C, and the DGX-Spark unified CPU-GPU memory system. The PCIe and NVLink machines have the same H100 GPU, isolating the interconnect’s (I/C) effect. We use Apache Arrow v21.0.0 [2] for CPU, cuDF v25.08 [36] for GPU, and Caliper [5] for instrumentation. For vector search, we use cuVS-enabled FAISS v1.13.0 [8] linked against libcuvs v25.08 [37]. Builds use CUDA 12.8, GCC 13, and Ubuntu 24.04, except for DGX Spark (CUDA 13.0). We use PostgreSQL 17 with pgvector v0.8.2 [16]. Dataset & Workload We use Vec-H with SF=1 where the dataset has 200K parts, ∼2.4M reviews, and ∼750K images. We embed reviews with Qwen 0.6B [57] (𝑑=1024, ∼9.8 GB of embeddings) and images with SigLIP2 [45] (𝑑=1152, ∼3.4 GB of embeddings), giving a Rel:VS data ratio of ∼ 1:12. In the figures we use suffix −𝑟 if the query runs vector search over reviews, and −𝑖 if it is over images. Engines. PostgreSQL with pgvector is used as the baseline as it supports all Vec-H analytical SQL+VS queries across multiple index types. To evaluate gpu and hybrid (CPU/GPU) execution, we use MaxVec (Section 4.3). PostgreSQL serves as a point of comparison for MaxVec’s CPU implementation. In all cases, we tune PostgreSQL’s configuration to use all available resources. For all engines, we load all data and indexes into memory before query execution. Total runtime comes from normal execution runs, while 7

Relational Operators

Runtime [ms, log] IVF1024

Vector Search

Q16-r

Data Movement

Q19-r+i

Q10-r

Index Movement

Q13-r

Other

Q18-i

Q11-i

Q15-r

1k 100

26x 12x

10

34x

45x

6x

17x

8x

6x

23x

8x

42x

47x

40x

18x

DNF

Exhaustive

Q2-i

10k 1k 100 2x

10

33x

19x

44x

8x

copy-di

u pc nv ie lin k gp u

or

cp

ct ve

pg

nv ie lin k gp u

u

pc

or ct ve

pg

copy-di

8x

cp

u pc nv ie lin k gp u

or ct ve

pg

copy-di

69x

45x

cp

u pc nv ie lin k gp u

or ct ve

pg

copy-di

21x

cp

u pc nv ie lin k gp u

or ct ve

pg

copy-di

cp

u pc nv ie lin k gp u

cp

ct ve

ct ve

u pc nv ie lin k gp u copy-di

pg

copy-di

cp

u pc nv ie lin k gp u

or

cp

ct ve pg

or

2x

10

or

100

pg

CAGRA

1k

copy-di

Figure 4: Vec-H per-query runtime with owning indexes (copy-di) and baselines. All bars run on GH200 except pcie, which runs on the H100 system. cpu and pgvector execute on the GH200 CPU, gpu and nvlink on the GH200 GPU. plus a small residual, which includes system overheads not belonging to a specific operator or transfer operation. Relational Operators and Vector Search represent the time to run their respective operators. Data Movement covers CPU↔GPU transfers of relational tables, Index Movement covers the transfer of the vector index structure (IVF/CAGRA) plus the embedding data if the index is dataowning (copy-di). For ENN, the movement of embeddings is counted in the data movement.

5.2

execution starts. The result shows that MaxVec on gpu beats cpu on every (index, query) pair by 2×–69×. Exhaustive search queries (ENN) on gpu are within ∼1.2×–1.6× of CAGRA, showing that GPU parallelism reduces the ENN VS cost significantly. Next, we look at the copy-di strategy, where the data and indexes start at the CPU and are copied to the GPU. NVLink (nvlink) or PCIe (pcie) interconnect is used depending on the hardware configuration. For ENN, the copy-di strategy using nvlink is 4×–19× faster than cpu. When pcie is used for ENN, the performance is a tie with cpu on most queries, with Q11, Q13, Q18 winning by 1.4×–3.7×. These results show that using ENN on GPU is a viable strategy when a fast interconnect is available, and ENN can be more robust with respect to tuning (i.e. oversampling in post-filtering[7] and choosing the right number of partitions for IVF [22] or ef_search for HNSW to achieve the requested recall [23]). On the other hand, ANN with copy-di is not competitive: IVF1024 and CAGRA on pcie are orders of magnitude slower than cpu. This shows that data movement in data-owning indexes from host to device is a bottleneck. A faster interconnect, like nvlink, narrows but does not close the gap. Vector index transfer dominates copydi on ANN, taking over 95% of wall time on most queries (∼85% on Q11). Note that the 𝑖𝑛𝑑𝑒𝑥_𝑐𝑝𝑢_𝑡𝑜_𝑔𝑝𝑢 () 1 mechanism used in FAISS, captured by the “Index Movement” component of the bars, is far from achieving the theoretical bandwidth of pcie and nvlink. We analyze this further in Section 5.4.

State-of-the-art Strategies on CPU and GPU

Figure 4 compares runtime of Vec-H queries when run on pgvector (cpu) and on MaxVec (cpu/gpu). MaxVec using cpu runs Vec-H 1.6×– 20× faster than pgvector on most (query, index) pairs. Comparing three vector search execution methods ENN, ANN with IVF, and ANN with graph (HNSW and CAGRA) indices, pgvector is faster in two cases (Q2, Q19 cagra), where its relational operators are faster. The vector search is faster in MaxVec in every case: 3.5×–8× with ENN (Q11 on pgvector times out at > 20-min), 1.6×–7.1× with ANN (130× on IVF1024 and 81× on CAGRA for Q11). One reason for the general VS performance difference is that MaxVec’s index and search implementation comes from FAISS, while pgvector implements its own. Another is the difference in vector operator design (Section 4.3), for example Q11 achieves a much higher speedup than other queries because MaxVec’s binary vector search operator takes the whole outer relation as a single query batch (Section 4.3), while pgvector expresses Q11 with a LATERAL join (Section 3) that performs one vector search operator call per each outer table tuple. MaxVec is consistently faster than pgvector and thus we use it as our CPU baseline for the rest of the experiments section.

Key Insight. With current data-owning vector indexes, executing vector search on a GPU does not pay off, even with fast interconnects, unless the vector index is GPU resident 5.2.2 Which operators does the GPU accelerate more? From Figure 4, we observed the gpu execution strategy provides a clear

5.2.1 CPU vs GPU execution. With the gpu strategy (Figure 4), the data and vector index are already in the GPU memory before query

1 https://faiss.ai/cpp_api/file/GpuCloner_8h.html

8

Exhaustive

71%

12%

39%

8%

41%

92%

47%

93% 75%

IVF1024

28%

80%

86%

53%

95%

97%

74%

43% 50%

IVF4096

57%

89%

90%

59%

97%

98%

79%

54% 25%

CAGRA

63%

94%

92%

62%

98%

98%

83%

64%

Q2

Q16

Q19

Q10

Q13

Q18

Q11

Q15

Table 4: Transfer times on reviews-table indexes (in ms).

100%

rel-op share of total GPU savings

Rel-op share of GPU Δt — GH200 (NVLink)

Index

PCIe 5.0 HtoD TotalP

HtoDP

NVLink-C2C Total HtoD

#cpy

size (GB)

Flat/ENN IVF1024 IVF4096 CAGRA

401 6510 7890 853

395 452 349 423

176 6156 7950 578

171 410 350 184

28.7 1266 1423 112

23.5 46.4 62 24.8

1 5121 20481 2

9.81 9.9 10.11 10.13

IVF1024H IVF4096H CAGRAC CAGRAC+H

425 -

423 -

187 -

184 -

4 14.5 27.4 0.8

2.5 9.9 24.8 0.76

3073 12289 2 1

0.004 0.017 10.13 0.307

P: pinned memory, C: cached graph, H: host-resident (via ATS). #cpy: total transfers

0%

Figure 5: Share of total 𝑐𝑝𝑢 to 𝑔𝑝𝑢 wall-time savings attributable to relational operators.

runtime. On the other hand, for most queries with ANN, the relational operators dominate. For ENN in hybrid the time spent on VS is 90%+. The exceptions are Q2, and Q18 where the smaller embedding column makes VS on CPU cheap ∼42–45 ms, and Q15, where the selective filter reduces the number of embeddings to be processed significantly. For ANN, this relationship flips and relational operators dominate, even when executed on the GPU. On CAGRA cpu-nvlink, where both run on the CPU, relational operators take 12×–150× longer than VS for 7/8 queries (e.g. 495 ms vs 3.3 ms on Q18). Moving the relational part to the GPU in hybrid-nvlink significantly improves runtime, reducing the gap to 1.2×–4.8×.

benefit when the data is pre-resident on GPU. In Figure 5, still on the GH200 system, we show the operator runtime savings of using the GPU compared to the CPU, with a fraction that captures the relational-operator acceleration: sharerel = (relCPU − relGPU )/(totalCPU − totalGPU ). Essentially, the larger the percentage, the bigger the share of the speedup that comes from accelerating the relational part of a query compared to the vector search. Above 50%, the benefit of the relational part is the majority. The per vector search method median relational operator share of runtime improvement is 87% for CAGRA, 77% for IVF1024, 84% for IVF4096, and 44% for ENN. We observe two trends: First, for ENN, since cpu execution is dominated by vector search, GPU benefits vector search more (Q16, Q19, Q10, Q13, Q11). Second, for ANN, even for the three queries (Q2, Q15, Q10) with the smallest relational operator improvement compared to VS, still the improvement of the relational operators is larger. This is a direct result of vector search being "cheaper" compared to relational operators. In this table, we include two configurations of IVF with 1024 and 4096 partitions, and we observe that the larger number of partitions makes VS faster and thus for the IVF4096 case, the relational operators improve relatively more compared to the IVF1024 case as the relational operator cost remains fixed.

Key Insight. In analytical SQL+VS queries, relational operators can be orders of magnitude more expensive than vector search. 5.3.2 Hybrid Execution vs cpu vs gpu. Hybrid execution beats cpu on 47 of 48 (query, index) pairs across pcie and gh200 machines. The only case where cpu wins is ENN Q2 on pcie. Compared to the gpu strategy, hybrid is slower but has significantly closed the performance gap. For example hybrid using nvlink under CAGRA is within 1.3–4.4×, and IVF within 1.6–5.7× of the gpu strategy. Key Insight. With hybrid execution and ANN vector search, we get the best of both worlds: no data permanently residing on the GPU, GPU-acceleration for relational operators, and vector search acceleration through ANN indexes. Still, hybrid is not optimal as the GPU is not used for VS, and depending on the query, intermediate results might have to be moved from the GPU to the CPU.

Key Insight. GPU execution yields a bigger improvement for relational operators compared to vector search.

5.3

Total

Hybrid Execution

5.4

The observations of Section 5.2 motivate a hybrid execution strategy: run relational operators on GPU and vector search on CPU. The hybrid strategy eliminates two large costs: the dominant indextransfer overhead of copy-di (Figure 4), and the large amount of GPU memory needed to keep a device-resident index in gpu. Figure 6 compares hybrid to the cpu and gpu strategies. We report two CPU runtimes, one per platform: the AMD EPYC in the H100-PCIe system (pcie) and the ARM CPU in the GH200-NVLink system (nvlink). As the CPUs in the two hardware configurations are different, each hybrid bar should be compared with the CPU bar from the same machine, e.g., pcie cpu to pcie hybrid.

Index Transfer Costs and Optimizations

The index movement throughput observed in Section 5.2 fell well below the interconnect’s peak bandwidth. We now break down where the time goes during index movement and evaluate the optimizations MaxVec employs to minimize the cost of index movement (Section 4.3.2). Table 4 reports per-index transfer time on both interconnects: on NVLink, moving ∼10 GB of embeddings (ENN) takes 28.7 ms while a similarly sized IVF1024 index takes 1266 ms, a 44× gap on identical data volume. Total is the wall-clock of FAISS index_cpu_to_gpu(). HtoD is the time spent in cudaMemcpy calls. The difference Total − HtoD is per copy call setup and CPU to GPU index transformation. To avoid profiler interference, Total is taken from an unprofiled run and HtoD from Nsight Systems [31]. The top half of the table

5.3.1 Where time goes in hybrid. In Figure 6, we observe two trends. For most queries, when using ENN, vector search dominates the 9

80

cpu

hybrid

cpu

hybrid

cpu

1.2k

120

250

600

60

hybrid

cpu

hybrid

80

1k

40

500

21x

45x

cpu

hybrid

8x

33x

44x

250

pc nv ie lin k gp u

pc nv ie lin k pc i nv e lin k gp u

pc nv ie lin k pc nv ie lin k gp u

pc nv ie lin k

pc nv ie lin k gp u hybrid

250

23x

500

500

8x

18x

26x

40x

19x

500

40

6x

cpu

200 8x

17x

150

2x 80

10

42x

400

80

800

8x

69x

cpu

hybrid

pc nv ie lin k pc nv ie lin k gp u

50

160

pc nv ie lin k pc nv ie lin k gp u

150

300

160

400

pc nv ie lin k pc nv ie lin k gp u

100

pc nv ie lin k pc nv ie lin k gp u

Exhaustive Runtime [ms] IVF1024

300

Q15-r

1.6k

47x

45x

Other Q11-i

800

400

200

6x

20

Q18-i

800

34x

2x 50

10

Index Movement

Q13-r

400

400

100

20

Q10-r

800

250

100

Data Movement

Q19-r+i

500

200

12x

CAGRA

Vector Search

Q16-r

pc nv ie lin k

Relational Operators Q2-i

cpu

hybrid

Figure 6: Vec-H per-query runtime under hybrid execution (VS on CPU, Rel on GPU). The pcie cpu and pcie hybrid run on the H100-PCIe system, while nvlink cpu, nvlink hybrid, and gpu, on GH200.

5.5

lists data-owning indexes (Section 5.2). The bottom half adds the optimized variants (𝑃, 𝐶, 𝐻 ) that we evaluate next. Pure HtoD bandwidth is not the bottleneck. HtoD when issuing a single cudaMemcpy call on a flat contiguous array of embeddings (Flat/ENN) reaches ∼ 24 GB/s on non-pinned PCIe 5.0 and ∼ 417 GB/s on NVLink-C2C. CAGRA’s HtoD does the same. This is the expected interconnect bandwidth for pageable memory [15]. Index movement is dominated by overhead. FAISS has not optimized the transfer. For CAGRA, total is ∼ 2× HtoD on PCIe and ∼ 4.5× on NVLink, mainly because of the HNSW→CAGRA conversion (Section 4.3.2). For IVF, transfer overhead is extreme. Embeddings are stored in many per-partition arrays, transferred through small memcpys instead of a single large HtoD transfer. Surprisingly, IVF1024 issues 5,121 cudaMemcpy calls and IVF4096 issues 20,481, roughly 5 per partition with mean size of ∼ 1.8 MiB on IVF1024 and ∼ 0.5 MiB on IVF4096. The effective throughput is < 2% of the theoretical maximum bandwidth. For index movement: data preparation and unoptimized data layout caps transfer throughput far below hardware peak performance. Pinning the memory and caching GPU indexes Pinning (𝑃) and graph caching (𝐶) were introduced in Section 4.3.2. They improve the HtoD bandwidth and avoid transformation overhead (Table 4). With (𝑃), ENN and CAGRA HtoD rise from ∼ 24 GB/s to near peak ∼ 55 GB/s on PCIe 5.0. But, the transfer bandwidth for IVF does not improve, the copies are too small for pinning to matter and percall HtoD setup dominates instead. With (𝐶), CAGRA’s Total index transfer time improves from 853 → 425 ms with unpinned memory in PCIe. With both 𝐶 and 𝑃, CAGRA is within ∼ 2 ms of HtoD and Total improves (578 → 187 ms pinned PCIe, 112 → 27.4 ms NVLink).

MaxVec Non-Owning Vector Indexes

In this section we evaluate the performance of non-data-owning indices for SQL+VS queries with the Host-residency optimization, which is enabled by ATS over the GH200’s coherent NVLink-C2C interconnect, a hardware capability not available in our PCIe machine (Section 4.3). First, in Table 4 (bottom) we measure the transfer costs of the non-data-owning indices’ metadata (𝐻 ). Specifically, we measure the time to move the index metadata (centroids for IVF, graph for CAGRA), which takes place at the start of every query. Compared to moving both the embeddings and index metadata, like data-owning indices, the index movement reduces from 1266 ms to 4 ms (316×) for IVF1024H , and from 112 ms to 0.8 ms (140×) for CAGRAC+H . We now evaluate the performance of full SQL+VS queries using a non-data-owning index with the copy-i and gpu-i execution strategies. copy-i moves the index structure at the start of every query, gpu-i takes advantage of the small size of the non-owning index structure (4 MB IVF1024, 307 MB CAGRA) and keeps it resident in GPU memory prior to query execution. Both strategies only move the embeddings the ANN search visits to the GPU during query execution. In Figure 7, we see that compared to the gpu strategy, both gpu-i and copy-i are ∼ 1.2 − 5.2× slower than gpu, while cpu is 2 − 69× slower than gpu (Figure 4). gpu is faster but the margin has improved. Compared to the cpu baseline on the GH200 system (cpunvlink from Figure 6), both copy-i and gpu-i are faster by 1–21×. We compare these non-owning strategies to hybrid in Section 5.6. Key Insight. By updating vector index design to non-owning, and harnessing modern unified-memory hardware, we can accelerate full SQL+VS queries on a GPU without having to store large data in GPU memory.

10

Relational Operators Q2-i

Vector Search

Q16-r

Data Movement

Q19-r+i

Q10-r

Index Movement

Q13-r

40 15

20

6

2.3x100

20 4.8x

16 2.3x

id br

py gp i ui gp u

8

co

id

py gp i ui gp u

br

co

hy

id

py gp i ui gp u

br

co

hy

id br

py gp i ui gp u

4.4x

co

id

py gp i ui gp u

br

co

40

hy

10

8

5

hy

id

py gp i ui gp u

br

80

1.3x 20

1.5x 16

2.2x

2.1x

hy

id

py gp i ui gp u

br

co

hy

id br

co

15

15

5.7x

10 15

8

hy

40

200 1.9x

hy

1.3x

1.3x

5

Q15-r

30

16

10

2.4x

3.5x 10

Q11-i

30

30

20

1.9x

co

1.6x

py gp i ui gp u

Runtime [ms] CAGRA(C+H) IVF1024(H)

30 12

Other

Q18-i

Figure 7: Vec-H per-query runtime on GH200-NVLink under the four optimized execution strategies (hybrid, copy-i, gpu-i, gpu). hybrid runs VS on the CPU, the others on the GPU. Speedups annotated relative to hybrid.

5.6

Choosing a Strategy

5.6.1 Which method should you choose? Based on all our empirical observations, we derive a decision heuristic to pick the best execution strategy depending on GPU memory availability and the type of vector index: Choose gpu when all data and indices fit on the GPU. When only the index fits, choose gpu-i for IVF and hybrid for CAGRA. When neither fits, hybrid is best, with copy-i as an alternative for IVF at large vector query batch sizes. The fastest method between hybrid, copy-i, and gpu-i can depend on many parameters: index type, batch size, scale factor, target recall, host hardware. To illustrate, we isolate and vary the query batch size on a pure VS micro-benchmark, tuned for 90% recall. For a DBMS with VS, a large batch size query is equivalent to a vector similarity join [54], which matches the Q11 VS pattern in our workload (here without the relational operators). We ask at what batch size does the GPU VS speedup amortize the cost of moving just the index (copy-i), and does it ever become worth it to have a data-owning index, which also moves the embeddings to GPU memory (copy-di). For IVF1024 (Figure 8, right) the index movement cost is amortized quickly. copy-i becomes better than cpu between 10–100 queries and converges to gpu performance at large batch sizes. For CAGRA (Figure 8, left), moving just the index structure is not enough, copy-i loses to cpu at every batch size, and only copy-di improves over cpu at above a 103 -query batch. Across our SQL+VS experiments, non-data-owning indexes make GPU execution the default for both VS and relational operators. The index structure is small enough to fit or be copied to the GPU and only ANN visited embeddings stream from host during search. Hybrid remains the recommendation for HNSW/CAGRA and when only the relational operators need to be accelerated. As DBMSs with VS support mature, the query optimizer will estimate data movement, operator runtimes, batch size, GPU memory budget, and recall target to identify the optimal per-query execution strategy.

Sections 5.2 through 5.5 evaluated six execution strategies for analytical SQL+VS queries: cpu, gpu, copy-di, copy-i, gpu-i, and hybrid. gpu is the fastest in every case, but it requires the embeddings, the relational data and the index to be pre-resident in GPU memory, which is scarce and expensive. Three alternatives enable GPU acceleration without GPU-resident embeddings or large index movement overhead: hybrid runs VS on the CPU and relational operators on the GPU. copy-i runs both on the GPU with the index shipped per query, and gpu-i runs both on the GPU with the index pre-resident. Looking at the optimized strategies for SQL+VS in Figure 7, there is no clear winner across all queries between hybrid, copy-i, and gpu-i. gpu-i beats hybrid on 7/8 IVF1024H queries but only 4/8 CAGRAC+H queries, where the differences in runtime are within 5%. copy-i is roughly even with hybrid on IVF1024H and slightly behind on CAGRAC+H . Q11, the batched deduplication query, is the strongest case for VS-on-GPU under IVF, where both copy-i and gpu-i run ∼2.5× faster than hybrid. The IVF-vs-CAGRA gap suggests IVF benefits more from GPU acceleration than CAGRA.

cpu

gpu

copy-i

copy-di

copy-di (pcie-pin)

CAGRA-C

theoretical

IVF1024

Time [ms]

103

102

101

100

100

101

102

Batch size

103

104 100

101

102

103

104

Batch size

5.7

Figure 8: Vector search operator runtime on the reviewstable index, as we vary the input query vectors batch size on GH200-NVLink. Dashed theoretical on IVF1024 assumes a single contiguous HtoD transfer.

Does the GPU Still Win Without HBM?

Finally, we look at the GB10 Superchip on DGX-Spark [30] (Table 2), which puts a Blackwell GPU and a 20-core ARM CPU on a single package, sharing one 128 GB LPDDR5x pool. We look at this 11

Q13-r

Q18-i

Q11-i

Q15-r

100 5.8x

60

20

1.9x30

10

2x

150

30

3.8x

300

100 5.7x

25

4.2x

150

3.6x

gh200

spark

gh200

spark

gh200

cp u gp u

cp u gp u

cp u gp u

cp u gp u

cp u gp u

cp u gp u

cp u gp u

cp u gp u spark

spark

gh200

spark

gh200

30

25 7x

45.1x

gh200

8.2x

50

500

spark

5.3x

32.7x

1k

8.7x

21.1x

3.4x

43.6x

200

3.5x

8.4x

23.4x

800

400

50

17.6x

26.4x

60

7.7x

18.6x

15x

1.6k

200

3.4x

7.8x

17.4x

2.5x

80

40x

400

60

200

1.5x

1.8x

41.6x

46.8x 300

200

9x

spark

5.3x 69x

cp u gp u

44.9x

1.5k

250 4.7x

5.1x

1.7x 1.9x40

10

300

160

500

cp u gp u

80

200 4.5x

33.6x

1.6x

600

cp u gp u

300

3.7x

400

cp u gp u

200

3.4x

600

cp u gp u

400

12.1x

20

Q10-r

Other

3k

160

80

Q19-r+i

Index Movement

gh200

spark

8.2x

cp u gp u

Q16-r

Data Movement

cp u gp u

CAGRA

Runtime [ms] IVF1024

Exhaustive

Q2-i

Vector Search

cp u gp u

Relational Operators

gh200

Figure 9: Per-query Vec-H runtime on DGX-Spark and GH200 for the cpu and gpu execution strategies. system for three reasons. First, it is a fraction of the cost of a GH200 system [29], so we can ask whether the SQL+VS speedups we reported on the GH200 generalize to less expensive hardware. Second, the GPU on Spark has no faster memory tier than the CPU: both draw from the same LPDDR5x at 273 GB/s, ∼15× slower than the HBM on a GH200, so any GPU speedup must come from compute (parallelism, Tensor units) rather than from a memory-bandwidth advantage. Third, the host-versus-device memory boundary that drove Sections 5.2 through 5.5 (where data resides, what crosses the interconnect, when to copy) does not exist. A SQL+VS query on this hardware can indistinctly run on the CPU or the GPU. Figure 9 compares the cpu and gpu execution strategies on Spark. We can see that gpu beats cpu on every (query, index) pair, by ∼ 2.5– 15× for ENN and ∼ 1.5–9× for ANN. The DGX-Spark, without the fast HBM bandwidth or the faster GPU is, as expected, slower in runtime compared to the GH200. The GH200 performs ∼4–8× faster for ENN and ∼1.5–13× faster for ANN on gpu. The architecture and low cost make the DGX-Spark an attractive system for SQL and SQL+VS workloads. On the single-tier unifiedmemory hardware the placement question of Sections 5.2 through 5.5 no longer applies, and the gpu strategy can always be used.

for heterogeneous CPU-GPU database systems. To answer the question, we developed Vec-H, an analytical SQL+VS benchmark extending TPC-H with two embedding tables and eight queries, and MaxVec, an execution engine for full SQL+VS queries on heterogeneous CPU-GPU hardware, with per-operator hardware placement and transparent data and index movement. We evaluated them across PCIe 5.0, NVLink-C2C, and DGX-Spark unified memory, varying execution strategies, index types, and index designs. From this analysis, we find that GPU acceleration does pay off for analytical SQL+VS, but the win is not driven by faster vector search. Most of the benefit comes from accelerating the relational part of the query. With the data-owning indexes used in current DBMS+VS systems, GPU vector search itself does not pay off even on fast interconnects. However, with non-data-owning indexes and hybrid execution strategies, GPU acceleration can be enabled without having to keep the data GPU-resident. The right choice of execution strategy depends on the index, interconnect, and the GPU memory budget. To benefit from GPU acceleration in practice, as DBMS+VS systems mature they need query optimizers that pick the optimal per-query execution strategy. A final important insight is that in unified memory architectures like the DGX Spark, running both the relational and the vector search components on the GPU always wins, providing a development direction for appliances focused on data analytics.

Key Insight. Single-tier unified-memory systems like the DGXSpark offer simpler data placement and GPU-acceleration at a fraction of the cost. Well-suited for database workloads and a possible direction for GPUs to better support relational engines.

7

ACKNOWLEDGMENTS

Work supported by a grant from the Swiss AI initiative and Swiss National Supercomputing Centre (CSCS) under project ID sm94.

6

CONCLUSION

REFERENCES [1] 2024. DuckDB Vector Similarity Search (VSS) Extension. https://github.com/ duckdb/duckdb-vss. Accessed: 2026-05-15. [2] Apache Software Foundation. 2026. Apache Arrow: A Cross-Language Development Platform for In-Memory Data. https://arrow.apache.org/. Accessed:

This work explores whether GPUs can accelerate analytical SQL+VS queries, where the cost lies between relational and vector search operators, and how vector indices and execution should be designed 12

2026-04-29. [3] Felipe Aramburú, William Malpica, Kaouther Abrougui, Amin Aramoon, Romulo Auccapuclla, Claude Brisson, Matthijs Brobbel, Colby Farrell, Pradeep Garigipati, Joost Hoozemans, et al. 2025. Theseus: A Distributed and Scalable GPU-Accelerated Query Processing Platform Optimized for Efficient Data Movement. arXiv preprint arXiv:2508.05029 (2025). [4] Martin Aumüller, Erik Bernhardsson, and Alexander Faithfull. 2020. ANNBenchmarks: A benchmarking tool for approximate nearest neighbor algorithms. Information Systems 87 (2020), 101374. https://doi.org/10.1016/j.is.2019.02.006 [5] David Boehme, Todd Gamblin, David Beckingsale, Peer-Timo Bremer, Alfredo Gimenez, Matthew LeGendre, Olga Pearce, and Martin Schulz. 2016. Caliper: performance introspection for HPC software stacks. In Proceedings of the International Conference for High Performance Computing, Networking, Storage and Analysis (Salt Lake City, Utah) (SC ’16). IEEE Press, Article 47, 11 pages. [6] Cheng Chen, Chenzhe Jin, Yunan Zhang, Sasha Podolsky, Chun Wu, SzuPo Wang, Eric Hanson, Zhou Sun, Robert Walzer, and Jianguo Wang. 2024. SingleStore-V: An Integrated Vector Database System in SingleStore. Proc. VLDB Endow. 17, 12 (Aug. 2024), 3772–3785. https://doi.org/10.14778/3685800.3685805 [7] Yannis Chronis, Helena Caminal, Yannis Papakonstantinou, Fatma Özcan, and Anastasia Ailamaki. 2025. Filtered Vector Search: State-of-the-Art and Research Opportunities. Proc. VLDB Endow. 18, 12 (Aug. 2025), 5488–5492. https://doi. org/10.14778/3750601.3750700 [8] Matthijs Douze, Alexandr Guzhva, Chengqi Deng, Jeff Johnson, Gergely Szilvasy, Pierre-Emmanuel Mazaré, Maria Lomeli, Lucas Hosseini, and Hervé Jégou. 2026. The Faiss Library. IEEE Transactions on Big Data 12, 2 (2026), 346–361. https: //doi.org/10.1109/TBDATA.2025.3618474 [9] Luigi Fusco, Mikhail Khalilov, Marcin Chrapek, Giridhar Chukkapalli, Thomas Schulthess, and Torsten Hoefler. 2024. Understanding Data Movement in Tightly Coupled Heterogeneous Systems: A Case Study with the Grace Hopper Superchip. arXiv preprint arXiv:2408.11556 (2024). [10] Google Cloud. 2025. ScaNN for AlloyDB. https://services.google.com/fh/files/ misc/scann_for_alloydb_whitepaper.pdf. Accessed: 2026-05-15. [11] Mark Harris. 2012. How to Optimize Data Transfers in CUDA C/C++. NVIDIA Technical Blog. https://developer.nvidia.com/blog/how-optimize-data-transferscuda-cc/ Accessed: 2026-04-30. [12] Yupeng Hou, Jiacheng Li, Zhankui He, An Yan, Xiusi Chen, and Julian McAuley. 2024. Bridging language and items for retrieval and recommendation. arXiv preprint arXiv:2403.03952 (2024). [13] Jeff Johnson, Matthijs Douze, and Hervé Jégou. 2021. Billion-Scale Similarity Search with GPUs. IEEE Transactions on Big Data 7, 3 (2021), 535–547. https: //doi.org/10.1109/TBDATA.2019.2921572 [14] Marko Kabić, Shriram Chandran, and Gustavo Alonso. 2025. Maximus: A Modular Accelerated Query Engine for Data Analytics on Heterogeneous Systems. Proc. ACM Manag. Data 3, 3, Article 187 (June 2025), 25 pages. https://doi.org/10.1145/ 3725324 [15] Marko Kabić, Bowen Wu, Jonas Dann, and Gustavo Alonso. 2025. Powerful GPUs or Fast Interconnects: Analyzing Relational Workloads on Modern GPUs. Proc. VLDB Endow. 18, 11 (July 2025), 4350–4363. https://doi.org/10.14778/3749646. 3749698 [16] Andrew Kane et al. 2025. pgvector: Open-Source Vector Similarity Search for Postgres. https://github.com/pgvector/pgvector. Accessed: 2026-05-15. [17] Guoxin Kang, Zhongxin Ge, Jingpei Hu, Xueya Zhang, Lei Wang, and Jianfeng Zhan. 2025. BigVectorBench: Heterogeneous Data Embedding and Compound Queries are Essential in Evaluating Vector Databases. Proc. VLDB Endow. 18, 5 (Jan. 2025), 1536–1550. https://doi.org/10.14778/3718057.3718078 [18] Hyunjoon Kim, Chaerim Lim, Hyeonjun An, Rathijit Sen, and Kwanghyun Park. 2025. Exqutor: Extended Query Optimizer for Vector-augmented Analytical Queries. arXiv preprint arXiv:2512.09695 (2025). [19] Jiale Lao, Andreas Zimmerer, Olga Ovcharenko, Tianji Cong, Matthew Russo, Gerardo Vitagliano, Michael Cochez, Fatma Özcan, Gautam Gupta, Thibaud Hottelier, et al. 2025. SemBench: A Benchmark for Semantic Query Processing Engines. arXiv preprint arXiv:2511.01716 (2025). [20] Yaowen Liu, Xuejia Chen, Anxin Tian, Haoyang Li, Qinbin Li, Xin Zhang, Alexander Zhou, Chen Jason Zhang, Qing Li, and Lei Chen. 2026. GPU-Accelerated Algorithms for Graph Vector Search: Taxonomy, Empirical Study, and Research Directions. arXiv preprint arXiv:2602.16719 (2026). [21] Clemens Lutz, Sebastian Breß, Steffen Zeuch, Tilmann Rabl, and Volker Markl. 2020. Pump Up the Volume: Processing Large Data on GPUs with Fast Interconnects. In Proceedings of the 2020 ACM SIGMOD International Conference on Management of Data (Portland, OR, USA) (SIGMOD ’20). Association for Computing Machinery, New York, NY, USA, 1633–1649. https://doi.org/10.1145/3318464. 3389705 [22] Vasilis Mageirakos, Bowen Wu, and Gustavo Alonso. 2025. Cracking Vector Search Indexes. Proc. VLDB Endow. 18, 11 (July 2025), 3951–3964. https://doi. org/10.14778/3749646.3749666 [23] Yu A. Malkov and D. A. Yashunin. 2020. Efficient and Robust Approximate Nearest Neighbor Search Using Hierarchical Navigable Small World Graphs.

IEEE Transactions on Pattern Analysis and Machine Intelligence 42, 4 (2020), 824– 836. https://doi.org/10.1109/TPAMI.2018.2889473 [24] Meta AI Research. 2025. FAISS v1.13.0, gpu/impl/IndexUtils.cu: getMaxKSelection. https://github.com/facebookresearch/faiss/blob/v1.13.0/ faiss/gpu/impl/IndexUtils.cu. Accessed 2026-04-13. [25] Chenghao Mo, Ben Karsin, Philip Adams, and Minjia Zhang. 2026. VecFlowChamfer: A GPU-based Data Management System for High-Performance MultiVector Search on Superchips. Proc. ACM Manag. Data 4, 1, Article 92 (April 2026), 26 pages. https://doi.org/10.1145/3786706 [26] Hubert Mohr-Daurat, Xuan Sun, and Holger Pirk. 2023. BOSS - An Architecture for Database Kernel Composition. Proc. VLDB Endow. 17, 4 (Dec. 2023), 877–890. https://doi.org/10.14778/3636218.3636239 [27] NVIDIA. 2026. CUDA C++ Programming Guide: Full Unified Memory with Hardware Coherency. https://docs.nvidia.com/cuda/cuda-programmingguide/02-basics/understanding-memory.html#full-unified-memory-withhardware-coherency. Accessed 2026-04-29. [28] NVIDIA Corporation. 2023. Matrix Multiplication Background User’s Guide. https://docs.nvidia.com/deeplearning/performance/dl-performancematrix-multiplication/. NVIDIA Deep Learning Performance Documentation. Accessed: 2026-04-29. [29] NVIDIA Corporation. 2024. NVIDIA Grace Hopper Superchip. https://www. nvidia.com/en-us/data-center/grace-hopper-superchip/. Accessed: 2026-04-29. [30] NVIDIA Corporation. 2025. NVIDIA DGX Spark Datasheet. https: //nvdam.widen.net/s/tlzm8smqjx/workstation-datasheet-dgx-spark-gtc25spring-nvidia-us-3716899-web. GTC 2025 Spring. Accessed: 2026-05-01. [31] NVIDIA Corporation. 2026. NVIDIA Nsight Systems. https://developer.nvidia. com/nsight-systems. Accessed: 2026-04-29. [32] Hiroyuki Ootomo, Akira Naruse, Corey Nolet, Ray Wang, Tamas Feher, and Yong Wang. 2024. CAGRA: Highly Parallel Graph Construction and Approximate Nearest Neighbor Search for GPUs. In 2024 IEEE 40th International Conference on Data Engineering (ICDE). 4236–4247. https://doi.org/10.1109/ICDE60146.2024. 00323 Oracle AI Vector Search User’s Guide. [33] Oracle Corporation. 2025. https://docs.oracle.com/en/database/oracle/oracle-database/23/vecse/aivector-search-users-guide.pdf. Accessed: 2026-05-15. [34] Pinecone. 2025. Pinecone: The Vector Database for AI Search and Retrieval. https://www.pinecone.io/. Accessed: 2026-05-15. [35] Mark Raasveldt and Hannes Mühleisen. 2019. DuckDB: an Embeddable Analytical Database. In Proceedings of the 2019 International Conference on Management of Data (Amsterdam, Netherlands) (SIGMOD ’19). Association for Computing Machinery, New York, NY, USA, 1981–1984. https://doi.org/10.1145/3299869. 3320212 [36] RAPIDS Development Team. 2026. cuDF: A GPU DataFrame Library. https: //github.com/rapidsai/cudf. NVIDIA RAPIDS. [37] RAPIDS Development Team. 2026. cuVS: Vector Search and Clustering on the GPU. https://github.com/rapidsai/cuvs. NVIDIA RAPIDS. [38] RAPIDS Development Team. 2026. RMM: RAPIDS Memory Manager. https: //github.com/rapidsai/rmm. NVIDIA RAPIDS. [39] Yasin N. Silva, Walid G. Aref, and Mohamed H. Ali. 2010. The similarity join database operator. In 2010 IEEE 26th International Conference on Data Engineering (ICDE 2010). 892–903. https://doi.org/10.1109/ICDE.2010.5447873 [40] Josef Sivic and Andrew Zisserman. 2003. Video Google: A Text Retrieval Approach to Object Matching in Videos. In Proceedings of the Ninth IEEE International Conference on Computer Vision - Volume 2 (ICCV ’03). IEEE Computer Society, USA, 1470. [41] Michael Stonebraker and Andrew Pavlo. 2024. What Goes Around Comes Around... And Around... SIGMOD Rec. 53, 2 (July 2024), 21–37. https://doi.org/ 10.1145/3685980.3685984 [42] Ji Sun, Guoliang Li, James Pan, Jiang Wang, Yongqing Xie, Ruicheng Liu, and Wen Nie. 2025. GaussDB-Vector: A Large-Scale Persistent Real-Time Vector Database for LLM Applications. Proc. VLDB Endow. 18, 12 (Aug. 2025), 4951–4963. https://doi.org/10.14778/3750601.3750619 [43] Transaction Processing Performance Council. 2022. TPC Benchmark H (Decision Support) Standard Specification. Technical Report. Transaction Processing Performance Council (TPC). https://www.tpc.org/TPC_Documents_Current_ Versions/pdf/TPC-H_v3.0.1.pdf Version 3.0.1, Accessed: 2026-05-15. [44] Transaction Processing Performance Council. 2024. TPC Benchmark DS (TPCDS) Standard Specification. https://www.tpc.org/tpcds/. Version 4.0.0, Accessed: 2026-04-29. [45] Michael Tschannen, Alexey Gritsenko, Xiao Wang, Muhammad Ferjad Naeem, Ibrahim Alabdulmohsin, Nikhil Parthasarathy, Talfan Evans, Lucas Beyer, Ye Xia, Basil Mustafa, et al. 2025. Siglip 2: Multilingual vision-language encoders with improved semantic understanding, localization, and dense features. arXiv preprint arXiv:2502.14786 (2025). [46] Nitish Upreti, Harsha Vardhan Simhadri, Hari Sudan Sundar, Krishnan Sundaram, Samer Boshra, Balachandar Perumalswamy, Shivam Atri, Martin Chisholm, Revti Raman Singh, Greg Yang, Tamara Hass, Nitesh Dudhey, Subramanyam Pattipaka, Mark Hildebrand, Magdalen Manohar, Jack Moffitt, Haiyang Xu, Naren 13

Datha, Suryansh Gupta, Ravishankar Krishnaswamy, Prashant Gupta, Abhishek Sahu, Hemeswari Varada, Sudhanshu Barthwal, Ritika Mor, James Codella, Shaun Cooper, Kevin Pilch, Simon Moreno, Aayush Kataria, Santosh Kulkarni, Neil Deshpande, Amar Sagare, Dinesh Billa, Zishan Fu, and Vipul Vishal. 2025. CostEffective, Low Latency Vector Search with Azure Cosmos DB. Proc. VLDB Endow. 18, 12 (Aug. 2025), 5166–5183. https://doi.org/10.14778/3750601.3750635 [47] Karthik Venkatasubba, Saim Khan, Somesh Singh, Harsha Vardhan Simhadri, and Jyothi Vedurada. 2025. BANG: Billion-Scale Approximate Nearest Neighbour Search Using a Single GPU. IEEE Transactions on Big Data 11, 6 (2025), 3142–3157. https://doi.org/10.1109/TBDATA.2025.3581085 [48] Jianguo Wang, Xiaomeng Yi, Rentong Guo, Hai Jin, Peng Xu, Shengjun Li, Xiangyu Wang, Xiangzhou Guo, Chengming Li, Xiaohai Xu, Kun Yu, Yuxing Yuan, Yinghao Zou, Jiquan Long, Yudong Cai, Zhenxiang Li, Zhifeng Zhang, Yihua Mo, Jun Gu, Ruiyi Jiang, Yi Wei, and Charles Xie. 2021. Milvus: A Purpose-Built Vector Data Management System. In Proceedings of the 2021 International Conference on Management of Data (Virtual Event, China) (SIGMOD ’21). Association for Computing Machinery, New York, NY, USA, 2614–2627. https://doi.org/10.1145/3448016.3457550 [49] Weaviate. 2025. Weaviate Vector Database. https://weaviate.io/. Accessed: 2026-05-15. [50] Chuangxian Wei, Bin Wu, Sheng Wang, Renjie Lou, Chaoqun Zhan, Feifei Li, and Yuanzhe Cai. 2020. AnalyticDB-V: a hybrid analytical engine towards query fusion for structured and unstructured data. Proc. VLDB Endow. 13, 12 (Aug. 2020), 3152–3165. https://doi.org/10.14778/3415478.3415541 [51] Bowen Wu, Wei Cui, Carlo Curino, Matteo Interlandi, and Rathijit Sen. 2025. Terabyte-Scale Analytics in the Blink of an Eye. arXiv:2506.09226 [cs.DB] https://arxiv.org/abs/2506.09226 [52] Bowen Wu, Dimitrios Koutsoukos, and Gustavo Alonso. 2025. Efficiently Processing Joins and Grouped Aggregations on GPUs. Proc. ACM Manag. Data 3, 1, Article 39 (Feb. 2025), 27 pages. https://doi.org/10.1145/3709689 [53] Jingyi Xi, Chenghao Mo, Ben Karsin, Artem Chirkin, Mingqin Li, and Minjia Zhang. 2025. VecFlow: A High-Performance Vector Data Management System for Filtered-Search on GPUs. Proc. ACM Manag. Data 3, 4, Article 271 (Sept. 2025), 27 pages. https://doi.org/10.1145/3749189 [54] Jiadong Xie, Jeffrey Xu Yu, and Yingfan Liu. 2025. Fast Approximate Similarity Join in Vector Databases. Proc. ACM Manag. Data 3, 3, Article 158 (June 2025), 26 pages. https://doi.org/10.1145/3725403 [55] Bobbi Yogatama, Yifei Yang, Kevin Kristensen, Devesh Sarda, Abigale Kim, Adrian Cockcroft, Yu Teng, Joshua Patterson, Gregory Kimball, Wes McKinney, et al. 2025. Rethinking Analytical Processing in the GPU Era. arXiv preprint arXiv:2508.04701 (2025). [56] Qianxi Zhang, Shuotao Xu, Qi Chen, Guoxin Sui, Jiadong Xie, Zhizhen Cai, Yaoqi Chen, Yinxuan He, Yuqing Yang, Fan Yang, Mao Yang, and Lidong Zhou. 2023. VBASE: Unifying Online Vector Similarity Search and Relational Queries via Relaxed Monotonicity. In 17th USENIX Symposium on Operating Systems Design and Implementation (OSDI 23). USENIX Association, Boston, MA, 377–395. https://www.usenix.org/conference/osdi23/presentation/zhang-qianxi [57] Yanzhao Zhang, Mingxin Li, Dingkun Long, Xin Zhang, Huan Lin, Baosong Yang, Pengjun Xie, An Yang, Dayiheng Liu, Junyang Lin, Fei Huang, and Jingren Zhou. 2025. Qwen3 Embedding: Advancing Text Embedding and Reranking Through Foundation Models. arXiv preprint arXiv:2506.05176 (2025). [58] Zili Zhang, Fangyue Liu, Gang Huang, Xuanzhe Liu, and Xin Jin. 2024. Fast vector query processing for large datasets beyond GPU memory with reordered pipelining. In Proceedings of the 21st USENIX Symposium on Networked Systems Design and Implementation (Santa Clara, CA, USA) (NSDI’24). USENIX Association, USA, Article 2, 18 pages. [59] Jiaxu Zhu, Jiayu Yuan, Kaiwen Yang, Xiaobao Chen, Shihuan Yu, Hongchang Lv, Yan Li, and Bolong Zheng. 2025. An Experimental Evaluation of Hybrid Querying on Vectors. Proc. VLDB Endow. 19, 2 (Oct. 2025), 183–195. https: //doi.org/10.14778/3773749.3773757

14

Related documents

• FPT=PTIME for Homomorphism Problems on Sparse-Incidence and Bounded-Independence Patterns#1006936
• kgsteward: a tool for building, reproducing and maintaining distributed knowledge graphs#1006937
• The Stochastic Shift: A New Evaluation Paradigm for Text-to-SQL with AI Operators#1006938
• SKYE: Write-Optimized Key-Value Store with Fine-Grained Control over Persistent Memory Accesses#1006939
• BI-Agent and BI-Bench: Towards Automating End-to-End Business Intelligence#1006940