Turbopuffer began as a specialized vector database, so it keyed documents around the address of each vector inside its approximate-nearest-neighbor index. That was an effective choice for cheap vector search on object storage—until the database grew into a broader search engine.
The vector-primary layout now imposes costs on unrelated workloads:
- Multi-vector documents duplicate non-vector data, increasing storage amplification
- Rebalancing vector clusters can move whole documents and rewrite every inverted-index reference
- ANN’s preferred blocks of roughly 100–200 documents constrain scans that need much larger batches
- Full-text search escaped the constraint by using independent posting blocks, making its index 10× smaller and some queries up to 20× faster
Turbopuffer v3 stops keying documents by ANN address and turns ANN into one secondary index among others. The important lesson is broader than vector search: when a system’s original specialty becomes its universal physical layout, every new capability inherits assumptions it did not choose.
The migration is also refreshingly unfinished. The new engine passes CI but remains slower than production; correctness came first, and the performance work is only beginning. Removing an architectural constraint is not the same as having already recovered the performance the old design earned over years of tuning.