Turbopuffer is rewriting its storage so the vector index is no longer the primary key for a document

A vector database is usually built so that the approximate-nearest-neighbour index is the authoritative home of a document, with everything else attached to it. Turbopuffer engineer Dan Harrison posted on 30 September that the next version of the company's storage engine does the opposite: the ANN index becomes a secondary index, and a small internal ID becomes the primary one. The post title is "RIP, vector database", and the Hacker News thread about it reached 206 points on 1 October.

The piece is a design note from the vendor about its own product, and the primary source is the blog post itself.

The problem the vendor is naming

Harrison opens with the current scale of the service: Turbopuffer hosts "1T+ documents", handles "10M+ writes/s" and serves "25k+ queries/s". A single index inside it supports "100B+ vectors serving 200 ms p99 reads at 1k+ QPS". The post then describes three limits of the current architecture, all consequences of using the ANN index as the primary key for a document.

The first is storage amplification: a document with several vectors has to duplicate its contents across the index. The second is write amplification, which Harrison states in one sentence: "updating just one vector can move hundreds of attributes and their indexes." The third is vectorisation: because block size is constrained to the ANN cluster size, roughly 100 to 200 documents, the engine cannot batch the way it would like, with blocks of thousands.

What v3 does

The redesign treats an internal, stable ID as the primary index. Both the user-supplied ID and the ANN index point at the internal ID as secondary indexes. A top-voted Hacker News comment frames the shift in database terms: "Your design choice went from a Postgres design pattern to a MySQL one." Postgres secondary indexes point at a tuple's physical location, which forces rewrites when a tuple moves. MySQL's secondary indexes point at the primary key, which is stable.

Harrison cites the full-text search rewrite that preceded this one as the pattern: when postings moved from averaging about 1.5 per block to a fixed 256, "the index got 10x smaller and queries got up to 20x faster". The status of v3 at posting is "100% of CI passes" with performance work still in progress. Benchmarks will be shared "in the coming weeks". The post does not give a date for a production rollout, and does not say what, if anything, a customer has to change in their own schema.

The consequence for a team

For a team using a vector database with frequent updates, or with multiple vectors per document, this is a vendor publicly saying its earlier architecture was wrong and that the write cost of an update was higher than it needed to be. The useful next step is a measurement rather than a migration: pull the current rate of index rewrites per update from the vendor's observability page or logs, and keep the number for a before and after. The HN discussion names LanceDB as having started with ANN-as-secondary, and raises SQL engines with built-in vector support, like CrateDB, ClickHouse and StarRocks, as options for teams that would rather not run a separate vector store at all.

A reader on a retrieval pipeline for an AI product can re-read their own write path with one question: when a single document changes, how many bytes move. By the vendor's own admission, that answer is about to get smaller.

Source

• Primary source: Turbopuffer: RIP, vector database, by Dan Harrison, 30 September 2026
• Discussion: Hacker News thread, 1 October 2026