Turbopuffer's 'RIP, Vector Database' Post Demotes ANN to a Secondary Index in v3

Turbopuffer, the search database built on object storage, said on Sept. 30 that its next architecture will stop keying all data by the vector index. The company titled the post "RIP, vector database". What it describes is narrower than the headline: approximate nearest neighbour search, or ANN, becomes "just another" secondary index, and a new primary index takes over.

The post was written by Dan Harrison, an engineer at turbopuffer, and reached 385 points on Hacker News. The company says 100% of its CI tests pass on turbopuffer v3 "as of earlier this month". It has not given a date for production rollout.

What changes inside turbopuffer v3

Today every piece of a document is addressed by where its vector sits in the ANN index: a cluster ID plus a local ID. Attributes, full-text postings and vectors all line up on those cluster boundaries, which hold 100 to 200 documents each.

Harrison's post names three costs of that layout.

Problem	What the post says causes it
Storage amplification	A document with several vectors repeats its non-vector data once per vector
Write amplification	Rebalancing in SPFresh, the clustering scheme turbopuffer uses, moves whole documents when one vector shifts
Limited vectorization	Query plans stay in blocks of 100 to 200 documents, where other engines batch far more

On the third row the post gives comparison points: DuckDB batches 2,048 rows, ClickHouse about 65,000 and Lucene 256 documents. A database that works in blocks of 100 to 200 cannot keep a modern CPU busy on a filter or an aggregation.

The post's summary of the decision: "We've pushed the vector-primary architecture as far as we can, and it's time to move on."

The numbers come from turbopuffer

Every figure here is the company's own. In a May 5 post by Nathan VanBenschoten, its Chief Architect, turbopuffer claimed 200ms p99 query latency at more than 1,000 queries per second over 100 billion vectors in one index. The newer post says its full-text search v2 produced indexes "10x smaller" and queries "up to 20x faster". In that rewrite the median posting block grew from about 1.5 postings to a fixed 256.

The company also says the system handles over 1 trillion documents, 10 million writes per second and 25,000 queries per second. No outside party is named as having tested any of these.

What the thread made of the headline

The user akras14 wrote on Hacker News: "They are not killing the vector database or vector search. They are killing the vector-primary storage layout." That reading matches the post's own text, which keeps ANN and demotes it.

The user sreekanth850 argued from the buyer's side: "SQL is already going to be part of almost any enterprise system. Adding a separate vector database introduces another moving part." That is an argument against standalone vector stores in general, and it is one the post does not make.

What a customer would ask

Anyone running turbopuffer for retrieval over agent memory or documents has one practical question: does v3 hold the latency in the May figures. The post commits to "share the benchmarks in public over the coming weeks" before rollout, and it gives no guarantee against a regression. It also withholds the design of the new primary index.

That makes the item to watch the benchmark post itself. Until it appears, v3 is a described architecture with passing tests and no published performance. Related database and agent-memory moves are covered in Supabase's $150 million round and Turso purchase and in Pi 1.0.