turbopuffer v3 drops the vector index as its primary index

From a vector-first design to a new primary index

In a post titled "RIP, vector database" dated September 30, 2026, engineer Dan Harrison said turbopuffer v3 changes how documents and indexes are laid out, written, compacted and queried. The company says the aim is to make search faster in every respect, while also preparing the ground for moving many more SQL queries to turbopuffer and making them fast.

turbopuffer launched as a serverless vector database (v1), built to serve very cheap and reasonably fast vector searches. According to the post, object storage as the source of truth provided the economics, and tiered NVMe SSD and memory caches provided the performance. Early customers that validated those tradeoffs included Cursor and Notion. The product later gained strong text and regex search (v2) and is used for non-search workloads, such as Linear's syncing engine.

Through all of this, the storage architecture stayed largely the same: the ANN vector index was the primary index, and every other index and query plan revolved around it. The company says this design constrained several query plans, such as GROUP BY and aggregations, and that it has pushed the vector-primary architecture as far as it can.

How the old layout worked

In v1, documents consisted of nothing but an ID and a vector. turbopuffer chose a hierarchical clustering index over the graph-based indexes that were prevailing at the time, because it suits object storage better. It started with SPANN and later migrated to SPFresh to support incremental indexing. Vectors are grouped into clusters, and the cluster centroids are clustered in turn to form a tree with a single root.

Everything is keyed by a ClusterId and a dense LocalId within each cluster, together called the ANN address. When attribute filtering and BM25 full-text search arrived in v2, their inverted indexes mapped attribute values and search terms to the ANN addresses of matching documents. Document attributes were also stored alongside the ID and vector. Later additions, including aggregations, regex search, fuzzy matching, sparse vector search and attribute ordering, were built on the same layout.

The post says the design persisted because it works very well for ANN search on object storage. According to turbopuffer, it has served single indexes of 100B+ vectors with 200 ms p99 reads at 1k+ QPS. Any major change therefore risks regressions in ANN performance.

Three costs of keying on the vector

The company names three problems with the current layout for non-vector queries.

• Storage amplification: the full contents of a document sit under its ANN address. With a single vector this is stored once, but multi-vector representations, such as document nesting or late interaction, force the contents to be duplicated per vector. The post says this is the reason for some of turbopuffer's limits.
• Write amplification: when a document is inserted, updated or deleted, SPFresh may rebalance vectors to keep recall high. Because everything is keyed by ANN address, that rebalancing moves the full document contents and the attribute and FTS indexes that reference it. According to the post, updating one vector can move hundreds of attributes and their indexes, and efforts to tune indexing throughput have started to hit diminishing returns.
• Limited vectorization: modern query engines work on blocks of values. The post cites DuckDB at 2,048 rows per batch, ClickHouse up to about 65k, and Lucene posting blocks of 256 documents, while turbopuffer's ANN index works best with clusters of around 100 to 200 documents. Scans such as aggregations read documents stored one block per cluster, so their block size is tied to cluster size.

As evidence that block size matters, the company points to its own full-text search. The first version partitioned posting lists along ANN cluster boundaries, so the median block held about 1.5 postings. FTS v2 moved to fixed blocks of about 256, and according to turbopuffer the index became 10x smaller and queries up to 20x faster.

Where v3 stands and what it means

The fix, according to the post, is to stop keying on the ANN address. The company calls this a non-trivial change and describes v3 as a new foundation expected to bring significant performance gains across all query plans. It reports a milestone earlier in September: 100% of CI passes on turbopuffer v3. The team started with correctness and says it will now work on making v3 both correct and fast, sharing progress as it goes. The post gives no release date, pricing or benchmark results for v3.

For users, the stated direction is clear: faster text, regex and vector queries, fewer constraints on multi-vector documents, and broader support for SQL-style queries such as aggregations. How much of that materializes will depend on the performance work still ahead, which turbopuffer says it will document publicly.