turbopuffer 正在对其存储架构进行重大重构。新引擎（内部代号为 “turbopuffer v3”）彻底改变了文档与索引的布局、写入、压缩及查询机制，旨在支持更大规模且更多样的查询计划。
作为最初主打高性价比向量搜索的无服务器数据库，turbopuffer 凭借对象存储的经济性与分层 NVMe SSD/内存缓存的性能，赢得了 Cursor 和 Notion 等早期客户的验证。随着产品演变为通用搜索数据库，其查询引擎虽不断扩展，但存储架构始终围绕近似最近邻（ANN）向量索引构建，这已成为进一步发展的瓶颈。
从 v1 到 v2：向量优先的局限
在 v1 版本中，turbopuffer 采用基于对象存储的分层聚类索引。向量被聚集成簇，形成树状结构，所有数据均通过 ClusterId 和 LocalId 组成的 “ANN 地址” 进行键控。这种设计使得 ANN 索引成为事实上的主索引。
v2 版本引入了属性过滤和全文搜索（FTS）等新查询计划。为了保持高召回率，系统建立了将属性值映射到 ANN 地址的倒排索引。然而，由于所有文档内容仍依附于 ANN 地址存储，这种 “向量优先” 的架构逐渐暴露出三大核心问题：
- 存储放大：在多向量表示场景下，非向量数据需随每个向量重复存储，导致冗余。
- 写入放大：向量聚类的重新平衡会触发整个文档及其关联索引的移动，严重制约索引吞吐量。
- 向量化受限：现代查询引擎依赖大块数据以实现 SIMD 加速和 CPU 流水线饱和，但 ANN 索引的最佳簇大小仅为 100–200 个文档，限制了其他查询计划（如全文搜索、聚合）采用更优块大小的能力。
v3 架构变革：ANN 退居次席
为解决上述问题，turbopuffer v3 的核心变革在于解耦数据与 ANN 地址的绑定关系，不再以 ANN 地址作为主键，而是将 ANN 索引降级为 “另一个” 次要索引。
据团队透露，截至本月初，v3 版本的持续集成（CI）通过率已达 100%。值得注意的是，相较于现网生产环境，v3 目前存在显著的性能回归。这主要因为当前阶段聚焦于基础设计的正确性，性能调优工作刚刚启动。团队选择公开这一过程，旨在透明展示从基础构建到性能优化的完整路径。
后续，turbopuffer 将陆续公布新架构的基准测试数据及优化细节。作为一个托管超万亿文档、处理每秒千万级写入和数万查询的搜索引擎，turbopuffer 正通过此次底层重构，为支持更复杂的查询场景奠定基础。