向量数据库已死？这篇技术檄文撕开了什么

「向量数据库已死」——这个标题本身就像一颗炸弹扔进AI基础设施圈。当所有人都在押注检索增强生成（RAG）需要专门的向量存储时，有人站出来说：你们搞错了方向。

导读：为什么现在要重读这篇"檄文"

2024年的AI工程圈有个诡异现象：每家做RAG的都在买向量数据库，但用起来处处别扭。延迟高、成本高、调试难。这篇被Cloudflare拦截的技术文章（原载Medium），恰好戳中了这个集体焦虑。

作者的核心论点很锋利：向量搜索不该是独立数据库，而该是通用数据库的一个功能。这个判断如果成立，意味着Pinecone、Weaviate、Qdrant们的商业叙事需要重写。

要点一：向量数据库的"独立"是个历史误会

作者追溯了技术演进的脉络。早期关系型数据库（如PostgreSQL、MySQL）确实不支持向量检索，这才给了专用产品生存空间。

但2023年之后，主流数据库的扩展能力已经质变：

• PostgreSQL通过pgvector插件，支持高达16000维的向量存储

• 查询性能在百万级向量上能做到毫秒级响应

• 支持HNSW（分层导航小世界图）和IVFFlat（倒排文件索引）两种主流近似最近邻算法

作者的原话是：「当通用数据库足够好时，专用数据库的维护成本就成了负资产。」

这里的成本不只是钱。多一套系统意味着多一层网络跳转、多一份数据同步逻辑、多一种故障排查语境。对于已经深度使用PostgreSQL的团队，这相当于把一条SQL查询拆成两个系统的RPC调用。

要点二：RAG的真实瓶颈从来不在向量检索

这是文章最犀利的部分。作者拆解了RAG管道的实际耗时分布：

• 文档解析与分块：占端到端延迟的30-50%

• 重排序（Reranking）模型推理：占20-35%

• 大语言模型生成：占15-40%

• 向量检索本身：通常<5%

「优化一个只占5%耗时的组件，却引入整套新基础设施——这不是工程理性。」

作者举了一个具体场景：某团队用专用向量数据库后，整体延迟从800ms降到750ms，但运维复杂度翻倍。真正的瓶颈其实是PDF解析器和重排序模型的批处理策略。

这个观察击中了行业的一个认知盲区。向量数据库厂商的营销话术，往往把"毫秒级检索"作为核心卖点，却避而不谈它在完整RAG链条中的权重。

要点三：嵌入模型的迭代正在瓦解"专用存储"的合理性

作者指出了更深层的趋势：嵌入模型（Embedding Model）的上下文窗口和表征能力在快速进化。

2023年的主流模型（如text-embedding-ada-002）输出1536维向量，需要专门的索引结构。但2024年的新模型：

• 上下文窗口从8K扩展到128K甚至1M

• 多模态嵌入统一了文本、图像、视频的表征空间

• 部分架构支持动态维度调整

这意味着什么？向量本身的"形状"在变化，而专用数据库的存储格式往往是固定的。pgvector的优势在于：它是PostgreSQL的一个扩展，跟着主版本迭代，不会被嵌入模型的演进甩下。

作者特别提醒了一个细节：很多团队现在需要存储"多向量 per 文档"——同一文本用不同模型生成多个嵌入，用于不同检索策略。专用数据库的schema设计往往僵硬，而关系型数据库的表结构灵活得多。

要点四：成本结构的真相被刻意模糊化了

文章用具体数字对比了两种方案的云账单：

专用向量数据库（以某主流厂商为例）：

• 存储：$0.10/GB/月

• 查询：$0.001/千次

• 但隐性成本：数据导出导入的ETL作业、跨系统一致性维护、额外监控告警

pgvector方案：

• 存储：沿用现有PostgreSQL实例，边际成本趋近于零

• 查询：本地计算，无按次计费

• 运维：DBA现有技能栈直接复用

「当VC补贴期结束，这些数字会教育市场。」作者的语气带着明显的讽刺。

更关键的是锁定效应。专用数据库的查询语法、索引调参、备份策略都是独家的，迁移成本随数据量指数增长。而pgvector的向量操作是标准SQL扩展，理论上可以无损迁移到任何兼容PostgreSQL的托管服务。

要点五：被忽视的替代方案正在成熟

作者没有只批评，也给出了建设性的技术选型建议：

1. pgvector + PostgreSQL

适合：已有PostgreSQL基础设施、向量规模<1000万、团队熟悉SQL生态

关键配置：shared_buffers调大、HNSW索引的m和ef_construction参数根据召回率要求调整

2. SQLite + sqlite-vss

适合：边缘部署、嵌入式场景、单节点百万级向量

优势：零运维、单文件部署、移动端友好

3. 云厂商托管方案（如AWS Aurora PostgreSQL with pgvector）

适合：需要自动扩缩容、不想自管服务器的团队

注意点：确认实例规格支持向量操作的内存需求

作者特别强调了sqlite-vss的案例：一个浏览器插件团队用它在客户端本地存储用户文档的嵌入，实现了完全离线的语义搜索。「如果向量数据库真的那么重，怎么解释一个SQLite扩展就能搞定？」

要点六：技术辩论背后的商业博弈

文章的后半部分转向了行业观察。作者指出，"向量数据库"作为一个品类被炒热，与2023年的AI投资泡沫高度相关。

具体现象：

• 多家向量数据库公司在2023年完成大额融资，估值逻辑基于"AI基础设施"叙事

• 技术会议上的演讲 slots 被厂商赞助内容占据

• Benchmark 测试往往选择对专用数据库有利的场景（超大规模、纯向量检索）

「这不是说专用产品没有价值，而是说它们的价值被系统性高估了。」

作者引用了一个内部数据点：某头部云厂商的向量检索服务，80%的调用量来自pgvector兼容的API，而非原生专用数据库客户端。用户用脚投票的趋势已经很明显。

要点七：什么时候真的需要专用向量数据库？

作者没有全盘否定，而是给出了诚实的边界条件：

• 十亿级以上向量规模，且查询模式极度不规则

• 需要混合索引（向量+稀疏向量+全文）的复杂检索，且通用数据库的扩展插件不成熟

• 团队完全零数据库运维能力，宁愿为托管服务付溢价

但作者随即补刀：「满足这些条件的团队，2024年可能不到5%。」

对于大多数RAG应用，作者的建议是：先用pgvector验证需求，遇到明确瓶颈再考虑专用方案。而不是反过来，先买专用数据库再想办法用起来。

要点八：对工程团队的具体行动建议

文章结尾给出了可落地的检查清单：

评估现有方案

• 测量RAG管道的真实耗时分布，确认向量检索是否为瓶颈

• 统计向量数据库的月度账单，包括隐性ETL成本

• 评估团队调试跨系统问题的平均耗时

迁移可行性分析

• 检查嵌入模型的输出维度，确认pgvector版本支持

• 测试HNSW索引在目标数据规模下的召回率和延迟

• 验证现有ORM/查询构建工具对pgvector的兼容性

渐进式实施

• 新功能直接用pgvector实现

• 旧数据通过双写或批量迁移逐步切换

• 保留专用数据库作为冷备份，直至完全验证

「技术债务的利息，往往比迁移成本更高。」这是作者对犹豫者的最后劝诫。

结语：这篇文章为什么值得被认真对待

抛开标题的挑衅性，这篇文章的价值在于它戳破了一个集体幻觉：AI应用需要专门的AI基础设施。

历史总是押韵。十年前，NoSQL数据库也曾宣称关系型数据库已死，最终结果是PostgreSQL和MySQL吸收了它们的优点。现在向量数据库面临同样的剧本。

对于正在做技术选型的团队，这篇文章提供了一个低成本验证的路径：用你已有的PostgreSQL，加上一个开源扩展，跑通RAG原型。数据会告诉你，是否真的需要为"专用"两个字付溢价。

如果你已经在用pgvector，欢迎在评论区分享真实踩坑经验。如果你坚持专用数据库不可替代，也请用具体场景和数据来回应——技术辩论最怕的是立场先行，证据缺席。