turbopuffer v3 demotes vector search to a secondary index in storage overhaul

turbopuffer retires its vector-first storage

Search infrastructure company turbopuffer has announced that version 3 of its platform rebuilds the storage architecture from the ground up, abandoning the design that made its name. In a blog post titled "RIP, vector database", written by engineer Dan Harrison and currently on the Hacker News front page, the company says v3 changes how documents and indexes are laid out, written, compacted and queried.

The core decision: turbopuffer is moving to a new primary index and demoting approximate nearest neighbor (ANN) search from the centre of the system to one secondary index among many. According to the post, the aim is to make every kind of search faster, vector search included, and to lay the foundation for running many more SQL queries quickly on the platform.

A short history of the vector-first design

turbopuffer launched as a serverless vector database, built for extremely cheap and reasonably fast vector search. Object storage served as the source of truth for the economics, with tiered NVMe SSD and memory caches supplying the performance. Early customers such as Cursor and Notion validated the tradeoffs, and version 2 later added strong text and regex search along with non-search workloads such as Linear's syncing engine.

In v1, a document was nothing but an ID and a vector. While graph-based indexes were the prevailing wisdom at the time, turbopuffer found hierarchical clustering worked better with object storage: it started with SPANN and later migrated to SPFresh to support incremental indexing. Vectors, IDs and attributes were all stored in a key-value map keyed by a cluster ID and local ID, together forming what the company calls the ANN address. That made the vector index the structural heart of the system.

Version 2 bolted attribute filtering and BM25 full-text search on top as inverted indexes pointing back to ANN addresses, and the company went on to ship aggregations, regex search, fuzzy matching, sparse vector search and attribute ordering, all still orbiting the vector-primary layout.

Three problems with a vector primary index

The architecture performs: turbopuffer reports single indexes of over 100 billion vectors serving 200 ms p99 reads at more than 1,000 queries per second. But the post identifies three structural costs that pushed the company to change course.

Storage amplification: because full document contents live under each vector's ANN address, multi-vector representations such as document nesting or late interaction duplicate the contents for every vector. The company says this is the cause of some of its more frustrating limits.

Write amplification: SPFresh rebalances vectors to keep clusters well grouped, and since everything is keyed by the vector's address, rebalancing cascades into moving whole documents plus the attribute and full-text indexes that reference them. Updating a single vector can shift hundreds of attributes, and efforts to tune indexing throughput have hit diminishing returns.

Limited vectorization: modern query engines process data in blocks, with DuckDB working in batches of 2,048 rows, ClickHouse up to roughly 65,000 and Lucene using 256-document posting blocks. turbopuffer's clusters hold around 100 to 200 documents, so every query plan is capped at that block size regardless of what would actually be optimal for it. The layout has also constrained plans such as GROUP BY and aggregations.

What happens next

The post, dated September 30, 2026, is explicitly the first in a series. turbopuffer says it wants to open up the doors and let readers follow the migration as it happens, which means the concrete shape of the new primary index is still to be described in future updates.

Why it matters

Vector databases were the breakout infrastructure category of the AI boom, and this is a prominent vendor in that category declaring the dedicated vector-database shape a dead end for its own roadmap. Retrieval workloads increasingly combine embeddings, keyword search, filtering and SQL-style aggregation within a single query, and turbopuffer's bet is that the winning architecture is a general-purpose, vectorized query engine on cheap object storage, where ANN is one access path among several rather than the organising principle. For teams building search and RAG systems, it is a signal that infrastructure chosen for vector search alone may not age well, and that object-storage-based engines now intend to compete with analytical databases on their own ground.