QUIVER puts vector search inside SPARQL—and ships the benchmark to test it

A new database paper makes a narrower—and more reproducible—claim than its largest speedup suggests. QUIVER adds dense-vector operations to the open-source QLever SPARQL engine, while the authors’ MIT-licensed repository includes the engine fork, data preparation, benchmark runners and plotting notebook.

That artifact release matters because QUIVER is not evaluating an answer model. It is testing where vector work happens in a knowledge-graph query plan.

Three changes, measured separately

The system registers tensor functions inside QLever, parses JSON-encoded vectors once while building the vocabulary instead of repeatedly at query time, and exposes a Faiss approximate-nearest-neighbor index through a virtual SPARQL SERVICE. In the paper’s BSBM-DVQ scan experiments, moving parsing to ingestion produced median speedups from 3.42× to 41.9× over RDFTensor where the baseline completed. Adding the index reached a best measured 250× speedup; the largest baseline run timed out, so the authors did not calculate a ratio there.

The real-data experiment extends English DBpedia with 2.36 million CLIP image vectors inside a 422 million-triple graph. For a single-type ranking query, vocabulary-time parsing reached 20× and the indexed configuration reached 97.8× over RDFTensor. For the graph-constrained image-similarity join, every non-indexed configuration exceeded the paper’s 30-second cutoff, while the indexed version completed in seconds.

These are author-reported results from one AMD Ryzen 9 9900X machine with 92 GB of memory. Each system-query-dataset combination was repeated up to 128 times, ending early after two 30-second timeouts; the paper reports medians and applies Bonferroni-corrected tests at α=0.01.

The score is latency, not semantic quality

The boundary is explicit in the evaluation. BSBM-DVQ uses embeddings of random-word labels to stress throughput, not meaning. DBpedia-MS uses CLIP image embeddings, but the authors do not evaluate whether those embeddings retrieve the best semantic matches. The approximate index also exposes the familiar recall-latency trade-off: lower search settings run faster, while recall is measured against a full scan.

One reporting wrinkle deserves care. The arXiv abstract says indexed BSBM speedup reaches 355×, while the paper’s contribution summary and Section 6 report 250× for the measured BSBM scan result. Until that difference is reconciled, 250× is the defensible section-level figure.

Why this clears the benchmark gate

QUIVER does not move BIRD or Spider 2.0, and it should not be read as evidence that a data agent answers questions more accurately. It clears a different bar: readers can inspect and rerun the claimed database mechanism. The repository instructions build the QLever fork and run both benchmark suites, while the data guide documents BSBM generation and the much heavier DBpedia preparation path.

The useful result is therefore architectural. Parsing vectors once removes repeated lexical work; an in-engine index turns some graph-constrained vector joins from timeout cases into executable queries. Whether those faster queries retrieve better evidence remains a separate benchmark.