turbopuffer's v3 Runs 88 Times Slower Than v2 on Ordered Queries, by Its Own Benchmark

turbopuffer, the search database whose early customers include Cursor and Notion, is rebuilding its storage layer so the vector index is no longer primary, and its own benchmark page shows the unfinished v3 running 88 times slower than v2 on one query type.

The company announced the change on September 30 in a post by engineer Dan Harrison titled "RIP, vector database". A companion v3 progress page publishes the regression as it stands, so that readers can "watch the lines move" as the team closes the gap.

What v3 changes and why

turbopuffer launched as a serverless vector database, with object storage as the source of truth and NVMe SSD and memory caches in front. In that first version, according to the post, a document was an ID and a vector, indexed with SPANN and later SPFresh so that writes could be incremental.

SPFresh comes from a SOSP 2023 paper led by Yuming Xu. Its authors report better latency and accuracy than global-rebuild designs with 1% of the DRAM and under 10% of the cores, at a 1% daily update rate.

Full-text and regex search came later, but the vector index stayed at the centre. The post says that design has "constrained several query plans, like GROUP BY and aggregations", and that the team has pushed it as far as it goes. Harrison names three costs:

• Storage amplification: a document with several vectors has its other contents duplicated once per vector.
• Write amplification: updating one vector "can move hundreds of attributes and their indexes".
• Limited vectorization: block sizes follow the ANN cluster size, which the post puts at 100 to 200 documents, rather than the thousands a scan would prefer.

The regression, query by query

The v3 page defines each benchmark point as v3 p90 latency divided by v2 p90 latency on the same workload. A value of 1 is parity. Hot ordering by an attribute is the worst case at 88, and hot full-text search is 19.

1. Order by attribute (hot)88 x
2. Full-text search (hot)19 x
3. Full-text search (cold)5.51 x
4. Hybrid search (hot)5.12 x
5. Order by attribute, filtered (hot)4.45 x
6. Vector search (hot)1 x
7. Vector search (cold)0.71 x

Source: turbopuffer v3 progress page, accessed 2026-10-03; vendor-supplied

Vector search is the only category at parity or better. The page attaches a note to the 0.71 figure: cold query latency is "inherently noisy", and the team does not expect v3 to reduce cold vector latency meaningfully.

The page's own text reads: as of September 5, 100% of CI passes on v3, and "performance regressed significantly from production". All figures are turbopuffer's own, run on its own workloads. No independent party has published a comparison.

What has already been fixed

A dev log dated October 2, by engineer Xavier Denis, says batched reads were added to the v3 full-text engine on September 8, for a roughly 9x speedup. Batching during the scoring phase is still to come.

The company has a precedent for large gains from changing block layout. FTS v2 moved to fixed blocks of about 256 postings, where v1's median block held about 1.5. The index got 10x smaller and queries up to 20x faster, per the post.

Full-text search	v1	v2
Median block size	about 1.5 postings	fixed blocks of about 256
Index size	baseline	10x smaller
Query speed	baseline	up to 20x faster

What customers can and cannot tell yet

Nothing on either page says when v3 replaces v2 in production, or whether customers can opt in. The ratios are also not absolute latencies, so a 19x multiple on a query that takes a few milliseconds is a different problem from 19x on one that takes seconds.

Publishing a regression before a release is unusual. Microsoft's WSL Containers reached general availability with a known gap, no Compose, disclosed at launch, and the Git 3.0 SHA-256 debate turns on exactly this question of when a storage-format migration is worth its cost.

The next data point is the benchmark page itself. The team has said it will update the charts as it writes up each change over the coming weeks.