向量数据库，被自己人发了讣告

一家做向量数据库的公司，亲手写下这个品类的讣告。

10月，数据基础设施圈接连出现三条看似不相关的消息：turbopuffer 发布博文《RIP, vector database》，宣告独立向量数据库品类走向终结；Databricks 在官方博客贴出 Lakebase Postgres 混合检索的工程实测——热向量查询最低 4 毫秒，0.5 CU 每月 31~40 美元可作生产基线；BigQuery 侧则有人把原生表、托管 Iceberg、开放目录三种表格式写成一份架构决策记录，逐层给出选择逻辑。

三条消息背后是同一个判断：AI 数据栈正在收敛。过去三年靠概念单飞的专用组件，正在被通用数据库和湖仓平台逐个内化，而决定胜负的，不再是发布会上的叙事，而是延迟、成本和容量的工程账。

📉 讣告由同行来写，才是品类终结的标志

品类死了，通常不是对手宣布的，是自己人宣布的。

最耐人寻味的是 turbopuffer 那篇博文。按理说，向量数据库是它安身立命的赛道，它却用「RIP, vector database」「安息吧，向量数据库」这样的标题，亲手给这个品类下了定论。消息经 网路冷眼 等技术观察者转发后在中文技术圈刷屏，配图就是那句醒目的讣告标题。

为什么一家从业者要否定自己的品类？把时间线摆出来就明白了：

• 2023 年前后：生成式 AI 爆发，独立向量数据库一度成为融资热词，「Embedding 一存、检索一查」的故事满天飞
• 2024 年：主流数据库纷纷内置向量能力，pgvector 系、各家云厂商原生能力陆续落地，专用组件的核心卖点被快速稀释
• 2025 年 10 月：Databricks 公布 Lakebase 混合检索实测数据，检索能力作为数据库标配的证据链补齐
• 几乎同期：turbopuffer 发文宣告品类终结，行业叙事完成切换

从「向量检索值一个独立公司」到「向量检索只是数据库的一个索引类型」，中间只隔了两年。

据多位长期观察数据基础设施的人士私下交流，这波收敛的推手很清楚：混合检索成了 AI 应用的标配需求——用户既要关键词匹配又要语义检索，单独维护一套向量库、再和业务库做数据同步，工程成本高到不成比例。当 Postgres 生态能一站式解决，独立品类就失去了存在的商业理由。

turbopuffer 的讣告与其说是告别，不如说是重新站位：检索能力正在下沉为基础设施的默认属性，比拼的重心从「有没有」变成「多快、多便宜、多省心」。

⏱️ 4毫秒和31美元：把玄学变成工程题

数据库做向量检索到底行不行？行业吵了两年，Databricks 直接甩出了秒表和账单。

10月15日，Databricks 在官方博客发布工程实测文章《Sizing Lakebase Search：Lessons from a Real App and 4 Million Passages》，用两个真实工作负载回答了「该给检索分多少资源」这个悬而未决的问题：一个是公司内部应用 Slide Hub，一个是 MIRACL 英文数据集，规模是 400 万条 passages。

结论给出了两个关键基线：热向量查询最低延迟 4 毫秒；0.5 CU 的规格，每月成本 31~40 美元，可以作为生产环境的起点基线。

这件事的产业意义，比数字本身更大。

过去关于「数据库能不能扛向量检索」的争论，大多停留在架构理念层面：有人引用论文证明 HNSW 在通用库里有瓶颈，有人拿 demo 截图证明可用。而 Databricks 这次做的是容量规划（sizing）——这是生产系统才需要回答的问题：给定数据量和查询负载，该买多少计算单元、预算多少、延迟长什么样。

换句话说，向量检索正在从「能不能用」的玄学阶段，进入「用多少 CU」的工程阶段。一个品类成熟的标志，就是它的采购决策可以从 PPT 辩论变成 Excel 测算。

当然要留一分清醒：这是厂商自家的实测文章，选的负载、测的路径天然偏向自己。4 毫秒是「热查询」的下限，冷查询、高并发、写入密集场景的表现，仍要靠用户自己压测。但方向是对的——把容量规划方法论公开出来，比喊十句「企业级」都管用。

🧊 BigQuery 三选一：湖仓没有银弹，只有分层

表格式之争吵了这么多年，有人终于把它写成了一份正经的决策记录。

在 BigQuery 生态里，一个湖仓表可以活在三个地方：一是原生表（Native Tables），存在 BigQuery 自有存储里，享受全部平台控制能力，但外部引擎想碰这份数据，必须经过 BigQuery 来读；二是托管 Iceberg（Managed Iceberg），Parquet 文件放进你自己的 bucket，任何持有对应 Storage 角色的人都能直接打开文件——代价同样明确，Google 自己的文档写明：它不支持授权视图（authorised views）、行级安全、表快照（table snapshots）、fail-safe 以及托管灾难恢复；三是开放目录中的 Iceberg（Iceberg in an Open Catalog），Spark 等其他引擎可以直接写这些文件，但维护工作量和目录服务的可用性，都交还给你自己扛。

三种选型，一句话对比如下：

这份 ADR 给出的决策逻辑相当克制：从原生表起步。只有当某个具名团队或管道必须直接读文件时，才把那一层迁到托管 Iceberg；只有当另一个引擎必须直接写文件时，才升级到开放目录。

这个「按层决策」的思路值得所有平台团队抄作业。真正的麻烦从来不是三种格式各有取舍，而是很多团队试图为整个平台一次性选定一种格式——殊不知每一层的读者、写者和控制要求都不一样。青铜层可能需要开放目录让 Spark 直写，服务层可能留在原生表里换取行级安全，中间夹一层托管 Iceberg 给下游分析团队直读，这才是真实世界的形态。

同理，删除（erasure）在开放目录场景下的处理也是这份记录的重点——当文件不归平台管，合规动作的归属就变了。开放性和控制力，从来是一枚硬币的两面。

🔄 收敛的终局：平台吃掉组件，工程吃掉叙事

当专用组件的卖点变成平台的默认功能，竞争就换了维度。

把三条消息放进同一张格局图里，收敛的趋势一目了然：

可以看到两条清晰的分化线：

横向上，工程纵深拉开差距。 Databricks 晒出的 4 毫秒和 31 美元，本质上是在卷「我用工程实测证明我靠谱」；BigQuery 那份 ADR 卷的是「我把取舍写透了你照着选」。相比之下，停留在概念层面的玩家，位置会越来越尴尬。

纵向上，平台价值决定天花板。 独立向量数据库即便检索性能不差，也架不住用户在平台上「顺手就有」——检索内化进 Lakebase、内化进 BigQuery 之后，用户少维护一套系统、少同步一份数据、少签一份合同。省下来的不只是钱，是整个运维心智。

据多位接近平台厂商的人士观察，下一步的收敛方向大概率是治理与合规：当 AI 应用直接消费业务库里的数据，行级安全、授权视图、审计这些传统数据库能力会原封不动地成为 AI 检索的准入门槛——这也正是托管 Iceberg 方案被 Google 自己列出的那几项「不支持」，未来最可能补齐的地方。

对从业者的启示有三条：

• 做平台的：别再堆 AI 概念，把容量规划文档和成本基线公开出来，这才是 2025 年的企业级
• 做选型的：放弃「一套格式走天下」的执念，按层决策，让每一层服务于它真实的读写方
• 做专用组件的：要么下沉到引擎内部做索引，要么上浮到场景里做方案，卡在中间的品类位置最危险

小结

turbopuffer 发讣告，Databricks 秒表计价，BigQuery 逐层做决策——三件事拼出了同一个终局：AI 数据栈的组件时代正在落幕，平台时代进入深水区。接下来比的不是谁的故事更性感，而是谁的 4 毫秒更真实、谁的 31 美元更能扛住生产流量、谁的取舍文档更能帮客户省钱。潮水退去之后，基础设施行业终将回到它最擅长的竞争方式：用工程换信任。