September 2026 Summaries

turbopuffer v3 is a planned storage-architecture overhaul that replaces its vector-centric primary index with a new primary layout in which approximate nearest-neighbor (ANN) search becomes a secondary index, aiming to improve vector, text, regex, and broader SQL-style query performance. The company originally built turbopuffer as a serverless vector database using object storage, hierarchical vector clustering, and cached NVMe and memory tiers, later adding attribute filtering, BM25 full-text search, aggregations, regex, fuzzy matching, sparse vectors, and ordering around the same ANN-address-based layout. While this design has enabled large-scale vector search, including 100-billion-vector indexes with 200 ms p99 reads, it causes storage duplication for multi-vector documents, costly write amplification when vector clusters rebalance, and small processing blocks that limit query-engine vectorization. By decoupling document storage and other indexes from ANN cluster addresses, v3 is intended to eliminate these constraints and enable more efficient batching, compression, scans, and indexing. The project has reached full continuous-integration correctness coverage and will next focus on performance benchmarking and parity before production rollout.

Turbopuffer has introduced native embedding to relieve customers of managing external embedding pipelines and to improve semantic search performance through end-to-end system optimization. Previously, embeddings were generated externally and serialized with search execution, leaving the query planner unable to overlap that work with other tasks. With native embedding, turbopuffer can generate embeddings in parallel with vector-independent operations such as reading index metadata, reducing latency; beta users Linear and Readwise reported savings of 150 milliseconds and an eightfold reduction in median embedding latency, respectively. The service remains configurable for workloads where embeddings can be reused or should be handled externally, and planned caching aims to prevent redundant embedding requests. Turbopuffer also plans broader integrated capabilities, including asynchronous namespace re-embedding, model evaluation and migration, native reranking, improved parsing and chunking, and search agents, building on its search infrastructure for trillions of documents and high write and query volumes.

Applied Compute and turbopuffer trained the open-weight Qwen3.6-35B-A3B model with reinforcement learning to perform code search across roughly 9,000 open-source repositories, comparing filesystem-based tools such as ripgrep with a precomputed hybrid turbopuffer index that combines BM25, embeddings, and reranking. The evaluation included narrow tasks requiring exact answers and code citations from a hidden target repository, and open-ended tasks requiring identification of repositories implementing abstract design patterns, with rewards balancing accuracy, citation support, precision, answer length, and tool-use efficiency. Training improved performance in both search environments, but the indexed-search agent achieved higher final quality while sharply reducing tool calls and relying far less on ripgrep; the bash-only agent instead increased its grep usage. The specialized model matched or exceeded frontier models on the narrow task and substantially narrowed the gap on open-ended search while operating at substantially lower cost and latency, although some frontier models remained stronger in particular comparisons. As corpus size grew, ripgrep latency scaled poorly while turbopuffer query latency changed little, supporting the use of precomputed indexes for large, frequently queried corpora, though the authors note that indexing, storage, update frequency, and embedding costs affect total system economics.