Aker reports up to 3× pgvector QPS with a reproducible cache artifact
The PVLDB paper’s density-aware vector-result cache beats fixed-threshold baselines, but its synthetic workload and single-thread setup define the limits of the claim.
A new PVLDB paper puts a concrete number on result caching for disk-backed vector search: Aker reports up to 2× QPS on SPACEV and 3× on TriviaQA versus pgvector’s PostgreSQL shared-buffer baseline, while using 0.8× and 0.6× the memory, respectively. The authors also released the C++ cache, pgvector integration and benchmark harness, and identify commit 9f0c6c2e as the code used for the paper’s results. (paper; artifact)
What Aker changes
Aker caches a query vector’s top-k neighbors and can reuse those results for a nearby query without traversing the underlying index. Unlike fixed-threshold baselines, each cached query gets an adaptive similarity threshold: dense regions tighten reuse while sparse regions can relax it. Its “del-consistency” policy applies deletions immediately but can defer insert visibility, accepting bounded staleness to avoid a full refresh on every write. The paper reports cache lookups below 0.1 ms and less than 1 ms combined lookup-and-insertion overhead on a miss. (paper)
The accuracy result is as important as throughput. At k=10, Aker stayed above 0.80 recall in the reported experiments and improved recall over single-threshold Potluck+ and Proximity+ by as much as 52.3 percentage points on SPACEV and 64.0 points on TriviaQA. Against DiskANN rather than pgvector, the gain depended on backend cost: Aker improved QPS only under the highest-skew SPACEV workload, but reached up to 2.4× QPS across all tested TriviaQA skews. (paper)
Read the ceiling correctly
These are not production-trace numbers. The authors say real request traces were unavailable, so they generated a 100,000-request “simZipf” workload with Zipf exponents 0.30, 0.60 and 0.99. SPACEV uses interpolated query vectors; TriviaQA uses 50 Mistral-7B-generated variants per question encoded with BGE-large. That design tests controlled semantic and temporal locality, but it does not establish how often a live application would produce reusable neighborhoods. (paper)
The setup is also deliberately narrow: pgvector 0.8.0, a single client thread, one four-socket Xeon Platinum 8276 server, and 10-million-vector SPACEV and SPHERE indexes. The headline multiplier is therefore a system result under stated cache-friendly distributions, not a universal pgvector speedup. (paper)
Still, this submission clears an important bar many database-agent claims do not: the artifact exposes the cache library, configuration modes, integration patch and benchmark harness, and pins the evaluation commit. The next useful number is an independent run on an unscripted query trace—not another peak multiplier. (artifact)
sources
comments · 0