2026年9月30日，Cursor与Notion背后的检索服务商turbopuffer发了一篇标题颇具挑衅意味的技术博客：《RIP, vector database》。一位长期深耕底层的工程师Dan Harrison宣布，团队启动了代号为turbopuffer v3的底层存储架构重写，彻底把ANN（近似最近邻）聚类地址从系统的物理主索引降级为普通二级索引。
这并不是说向量检索不需要了，而是团队承认了一件残酷的事实：过去几年把空间向量当成整套数据库物理骨架的做法，在工程上撞了南墙。当大模型应用从单一的稠密向量检索，走向多向量、属性过滤和全文混合检索时，原有架构引发了极其严重的存储与写入放大。
甜蜜期借来的技术债
turbopuffer最初能打动市场，靠的是极致的单位经济账。它放弃了行业里耗内存的HNSW图索引，参考学术界SPANN与SPFresh算法，在对象存储之上搭建基于质心树的分层聚类系统。
这套设计将对象存储作为持久化事实来源，搭配本地NVMe与内存缓存，把高维向量分群归类。每个向量簇分配一个ClusterId，簇内向量获得一个LocalId，两者拼成的ANN地址就是底层键值数据库的物理主键。
在只有单一向量与简单ID的时代，这种设计轻盈且高效。可随着企业场景演进，用户不仅要搜相似度，还要做多属性过滤、BM25全文检索和多向量匹配。为了在聚类结构上支持这些能力，turbopuffer把整篇文档的内容和属性直接塞进了ANN地址之下，倒排索引也只能映射到这个空间聚类地址。
空间几何关系只适合检索，一旦充当物理主键，每一次微小扰动都是灾难。
问题在写入与更新时全面爆发。SPFresh算法包含一种自平衡协议，当新数据写入导致局部向量分布漂移时，系统会自发拆分并重新聚类以保证召回率。一旦向量在簇间发生迁移，其对应的ANN物理地址随之改变。
这意味着，改动一个向量，整篇文档的所有标量属性、甚至数百个倒排索引项都要跟着全量搬迁。如果一篇文档需要多向量表征，整篇内容就得按向量数量翻倍拷贝。在现网单Namespace承载每秒10,000次写入、32 MB/s吞吐的上限压迫下，原本为向量检索量身定制的存储模型，反过来成了吞噬I/O吞吐的绞索。
此外，现代分析引擎如DuckDB习惯单批次扫描2048行，ClickHouse可达数万行，而turbopuffer原有的聚类块仅能容纳100至200个文档，极大地限制了非向量扫描的矢量化硬件加速潜力。
重构带来的性能深渊
解法在概念上很直接：让文档以独立ID作为物理主键，将ANN剥离为二级索引。但在工程实现中，这无异于给飞行中的飞机换引擎。
turbopuffer公布的数据坦率得令人惊讶。2026年9月5日，v3引擎通过了100%的持续集成测试，但同步放出的初始基准测试显示，系统在非向量路径上陷入了严重的性能衰退：
热点全文检索的p90延迟暴涨到了v2的126倍，热点属性排序恶化了97倍，最常用的热点混合检索延迟也是旧版的57倍。即便是冷启动全文检索与带过滤属性排序，延迟也分别放大了11倍和4.63倍。
唯一的慰藉在于纯向量查询：热点纯向量搜索延迟与旧版基本持平（1.0倍），冷启动甚至由于去除了捆绑负载而微幅改善至0.83倍。
- 风险.v3目前仍处于刚跑通逻辑的极早期阶段，官方尚未给出生产环境迁移工具与正式上线时间表，依赖全文混合检索的生产集群切勿盲目跟进。
这种百倍级别的延迟滑坡，是关系解耦后查询规划器尚未优化、二次回表与内存布局未对齐时的典型工程阵痛。这也直接回答了为什么此前几乎所有专用向量数据库都在逃避重构：在对象存储的高时延网络环境里，解开紧密耦合的聚类结构，前期必然要付出惨重的远端I/O对价。
专用检索引擎的退路与终局
在存储架构的十字路口上，行业早已分化出几大派系：turbopuffer与Pinecone押注对象存储原生加多级缓存，承受着跨网络I/O的严苛约束；Qdrant坚持本地磁盘分段与内存映射，Weaviate走分片存储与HFresh混合路线；另一侧，pgvector等通用关系型扩展则在背后紧追不舍。
此前，turbopuffer公布的超大规模技术目标是针对1000亿个1024维向量（约200 TiB原始数据），通过二进制与RaBitQ量化把开销降至十六分之一，在单索引上以超1,000 QPS实现200毫秒的p99延迟。然而现实给所有人的教训是，AI检索不可能只靠纯向量撑起全场。真实业务系统充斥着租户隔离标签、状态标记与精确关键词匹配。
当专用向量引擎不得不将向量降级为普通二级索引，去补足列式扫描、倒排列表和查询优化的欠账时，它实质上是在向传统检索数据库低头靠拢。剥掉向量至上的激进外衣，工程世界并没有捷径可走。