RIP, vector database
Turbopuffer is moving from a vector-primary storage architecture to a new design in v3, demoting the ANN index to a secondary role to reduce write amplification.
read it Provides a rare, detailed engineering breakdown of why vector-primary database architectures hit limits and how shifting to a secondary index design solves write amplification.
summary
Turbopuffer is overhauling its storage architecture in version 3, demoting the ANN vector index from a primary role to a secondary index. Previous versions used vector cluster addresses as primary storage keys, which triggered severe write amplification and data duplication during updates. Version 3 introduces stable internal primary keys, mirroring traditional database patterns to unblock performance across vector, text, and relational queries.
key points
- Previous versions used ANN cluster addresses as primary keys, causing updates to trigger massive cascading rebalances across all attribute and full-text indexes.
- Multi-vector representations forced complete duplication of document attributes for every single vector.
- Version 3 adopts an internal segment and document ID as the primary index, turning ANN into a secondary index to decouple storage layout from vector clusters.
who should read it
Backend and database engineers interested in storage layout tradeoffs and search engine internals.
discussion positive
consensus
Most participants recognized the shift as a classic database design trade-off, comparing it to MySQL versus Postgres indexing patterns and noting that other modern stores like LanceDB already treat ANN as a secondary index.
pushback
A few participants expressed skepticism over vector-database marketing cycles and questioned whether adding indirection for vector lookups will hurt cold query performance.
> This write amplification is large enough that our efforts to tune indexing throughput have started to hit diminishing returns.
> don't key on the ANN address. That is precisely the change turbopuffer v3 makes. As you can imagine, it is not a trivial change.
This is a direct parallel to how Postgres and Mysql built indexes.
Your design choice went from a Postgres design pattern to a Mysql one. The difference is the reindexing cost vs the lookup cost - Postgres optimized for lookup and Mysql does for indexing on writes. Or more accurately, Postgres was better with good schema design using …
It maps the architecture change directly to classic database trade-offs between Postgres-style and MySQL-style index lookups.
Generated by an LLM from the article and thread. Check the sources before relying on it.