turbopuffer v3为何告别向量优先
turbopuffer v3正在重做 turbopuffer 的存储架构。项目最初是面向对象存储的无服务器向量数据库，依靠分层缓存降低成本，并围绕近似最近邻（ANN）索引组织文档、属性和查询计划。随着产品加入属性过滤、BM25 全文搜索、正则、模糊匹配、稀疏向量和聚合等能力，这种设计逐渐成为限制。
从ANN主索引到通用查询基础
旧架构把完整文档内容挂在 ANN 地址下。多向量文档因此可能重复保存内容；向量重平衡还会连带移动属性和全文索引，放大写入成本。不同查询计划也被迫使用适合向量簇的较小数据块，难以充分利用批处理、压缩和 SIMD。文章给出的例子是，独立存储并采用固定大小区块后，全文索引体积曾缩小十倍，查询速度最高提升二十倍。
v3的核心变化是更换主索引，让 ANN 成为普通的次级索引。这样，文本、属性、聚合和扫描可以采用各自更合适的布局与区块大小，理论上也为更多 SQL 查询提速铺路。团队表示，v3 的持续集成测试已经全部通过，接下来会在公开性能调优中争取并超越现有版本的性能水平。
关键问题仍是向量搜索性能
这不是一次没有代价的抽象升级。原有向量优先架构已经被用于超大规模 ANN 服务，任何存储重构都可能损害召回率、延迟或吞吐。当前公开信息主要证明了 v3 的正确性里程碑，还没有给出完整的生产基准、迁移细节或回归数据。因此，最值得关注的不是“向量数据库是否消失”，而是新主索引能否在保住 ANN 表现的同时，让混合搜索和非向量查询真正受益。