向量数据库泡沫破裂：为什么PostgreSQL正在吞噬专用向量引擎的市场

过去三年，向量数据库赛道堪称AI浪潮中最火热的细分领域之一。Pinecone拿到了红杉领投的1.38亿美元融资，Weaviate募资5000万美元，Milvus背后的Zilliz更是拿下了超过1亿美元的投资。一时间，似乎每个做AI应用的团队都需要一个专用向量数据库来存储和检索embedding。

但进入2026年，风向正在悄然改变。越来越多的团队发现，他们花大力气引入的专用向量数据库，带来的收益远不如预期——而PostgreSQL的一个扩展插件pgvector，正在悄无声息地吞噬这个市场。

一、专用向量数据库的崛起逻辑

要理解这场变革，先要回顾专用向量数据库为什么会火起来。2022年底ChatGPT发布后，RAG（检索增强生成）成为AI应用最主流的落地模式。核心思路很简单：把文档切块、做embedding、存入向量数据库，用户提问时用向量相似度搜索找到最相关的片段，再喂给大模型生成回答。

这个流程听起来简单，但工程实现上有一个关键瓶颈：传统关系型数据库并不擅长高维向量的相似度搜索。一个1536维的embedding做余弦相似度计算，在百万级数据量下如果用暴力扫描，延迟可能达到秒级，完全无法满足实时检索的需求。

专用向量数据库的核心卖点就在于此——它们内置了ANN（近似最近邻）算法，比如HNSW（分层可导航小世界图）和IVF（倒排文件），可以在百万甚至亿级向量中实现毫秒级检索：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
# Pinecone Python SDK 示例

import pinecone



pinecone.init(api_key="YOUR_API_KEY", environment="us-east1-aws")

index = pinecone.Index("my-rag-index")



# 插入向量

index.upsert([

    ("doc-001", [0.1, 0.2, 0.3, ...], {"source": "handbook", "page": 12}),

    ("doc-002", [0.4, 0.5, 0.6, ...], {"source": "handbook", "page": 45}),

])



# 相似度搜索

results = index.query(

    vector=[0.15, 0.25, 0.35, ...],

    top_k=5,

    filter={"source": {"$eq": "handbook"}}

)

这种方案确实有效，但代价是什么？你需要引入一个全新的基础设施组件，学习一套新的查询语言，维护数据同步管道，还要为托管服务支付不菲的费用。Pinecone的起步价是每月70美元，按存储量和请求量计费后，中等规模应用很容易突破每月500美元。

二、pgvector：从”够用”到”好用”的逆袭

pgvector是PostgreSQL的一个开源扩展，由Andrew Kane在2021年创建。最初它只支持暴力扫描，性能上完全无法与专用向量数据库相提并论。但这个项目进化速度惊人：

到了0.5.0版本引入HNSW索引后，pgvector的性能已经足以在大多数场景下与专用向量数据库掰手腕。在百万级向量、1536维的场景下，pgvector的p99查询延迟可以稳定在50ms以内，与Pinecone等托管服务的差距已经缩小到可以忽略的程度。

更关键的是，pgvector让你在PostgreSQL内完成一切——向量存储、相似度搜索、元数据过滤、事务一致性，全部用SQL搞定：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
-- 创建带向量列的表

CREATE TABLE documents (

    id BIGSERIAL PRIMARY KEY,

    content TEXT,

    embedding VECTOR(1536),

    source TEXT,

    created_at TIMESTAMPTZ DEFAULT NOW()

);



-- 创建HNSW索引

CREATE INDEX ON documents USING hnsw (embedding vector_cosine_ops)

WITH (m = 16, ef_construction = 64);



-- 相似度搜索 + 元数据过滤（单条SQL搞定）

SELECT id, content, source,

       1 - (embedding <=> $1::vector) AS similarity

FROM documents

WHERE source = 'handbook'

  AND created_at > '2025-01-01'

ORDER BY embedding <=> $1::vector

LIMIT 5;

注意最后这段查询：向量相似度搜索和传统的关系型过滤条件在一条SQL语句中完成。这在专用向量数据库中往往需要两步——先做向量搜索，再用元数据过滤——或者依赖数据库自己实现的过滤逻辑，灵活性远不如SQL。

三、性能对比：专用引擎还剩多少优势？

当然，专用向量数据库并非没有优势。在极端场景下，它们的性能仍然领先。关键问题是：这个优势在多大的数据量级上才显著，以及你的应用是否真的需要？

根据多项公开基准测试（包括Qdrant官方benchmark和独立社区的测试），大致的结论如下：

现实是，绝大多数RAG应用的向量数量在10万到500万之间——这个区间内，pgvector的性能完全够用。真正需要处理亿级向量的场景（比如全网搜索引擎、大规模推荐系统）屈指可数，而那些场景通常有专门的工程团队，选择Milvus或Qdrant自建集群才是合理的。

四、运营成本：被严重低估的隐性代价

技术选型时，开发者往往只关注查询延迟这一项指标，却忽略了引入新基础设施带来的隐性运营成本。这些成本在实践中经常比性能差异的影响更大。

1. 数据一致性问题

使用专用向量数据库时，你的业务数据（用户信息、文档元数据、权限控制）存在PostgreSQL或MySQL中，而向量数据存在Pinecone或Weaviate中。这意味着每次写入都需要双写，每次更新都需要同步两个系统。一旦同步管道出问题（网络抖动、进程崩溃），就会出现数据不一致：

• 文档已在PostgreSQL中删除，但向量仍留在Pinecone中，搜索到”幽灵”结果
• 文档内容已更新，但旧向量未被替换，搜索返回过时信息
• 权限变更后，向量数据库中的旧权限标记未同步，导致越权访问

而pgvector方案下，向量数据和业务数据在同一个数据库中，天然享受ACID事务保证。一次UPDATE语句同时修改内容和向量，要么全部成功，要么全部回滚，不存在中间状态。

2. 运维复杂度

每多一个基础设施组件，就多一份运维负担：监控、备份、升级、故障排查。如果你的团队已经在维护PostgreSQL，那么pgvector只是一个扩展插件，几乎不增加额外运维成本。而引入Pinecone虽然省去了自建运维，但引入了供应商锁定和成本不可控的风险。

3. 查询能力的降级

专用向量数据库的过滤能力通常远弱于SQL。比如你需要在向量搜索结果上做聚合统计（按source分组计数）、关联查询（JOIN用户表获取作者信息）、复杂条件组合（多列OR/AND嵌套），这些在pgvector中就是标准SQL语法，而在专用向量数据库中要么不支持，要么需要额外查询再在应用层拼接。

五、什么时候仍然需要专用向量数据库？

说了这么多pgvector的优势，并不意味着专用向量数据库没有存在的价值。以下场景中，选择专用引擎仍然是明智的：

场景一：亿级以上向量规模。当你的向量数量超过1亿，pgvector的单机HNSW索引会面临内存压力。虽然可以通过Citus分片或Multiple Partition来解决，但工程复杂度急剧上升。此时Milvus或Qdrant的分布式架构更有优势。

场景二：极低延迟要求。如果你的应用要求p99延迟在5ms以内（比如实时推荐、高频广告竞价），专用向量数据库的内存优化和索引算法优势仍然明显。pgvector在百万级数据上能做到15ms左右，但想压到5ms以下比较困难。

场景三：多模态向量混合检索。一些专用向量数据库开始支持稀疏向量（sparse vector）、多向量（multi-vector）等高级特性，这些在pgvector中尚在开发阶段。如果你的检索场景涉及复杂的混合检索策略，专用引擎可能更成熟。

但请注意，以上场景加起来在整个AI应用市场中的占比可能不到10%。对于90%的团队来说，pgvector就是正确且足够的选择。

六、更深层的技术规律：通用引擎吞噬专用引擎

向量数据库的故事并非孤例。回顾数据库发展史，类似的模式反复出现：

• 图数据库：Neo4j曾被视为图查询的唯一选择，但随着PostgreSQL的递归CTE和Apache AGE扩展成熟，大量中等规模的图查询场景被PostgreSQL吸收
• 时序数据库：InfluxDB和TimescaleDB曾激烈竞争，最终TimescaleDB（同样是PostgreSQL扩展）证明了通用引擎+扩展模式的竞争力
• 搜索引擎：Elasticsearch在全文检索领域地位稳固，但PostgreSQL的全文搜索和pg_trgm扩展覆盖了大量中小规模场景
• 键值存储：Redis几乎垄断了缓存领域，但PostgreSQL的UNLOGGED表+覆盖索引在许多场景下也能胜任

这个规律可以总结为：专用引擎在诞生初期有显著的性能优势，但随着通用引擎的扩展生态成熟，性能差距逐渐缩小，直到大多数场景下通用引擎”够用”——这时专用引擎的市场就会急剧收缩到少数极端场景。

SQLite也在上演同样的故事。sqlite-vec扩展的出现，让SQLite也能做向量搜索。对于那些嵌入在移动端或边缘设备的AI应用来说，SQLite+sqlite-vec可能是最轻量的选择，不需要任何额外的网络服务。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
-- SQLite + sqlite-vec 示例

.load ./vec0



CREATE VIRTUAL TABLE doc_embeddings USING vec0(

    embedding FLOAT[1536]

);



INSERT INTO doc_embeddings(rowid, embedding)

VALUES (1, '[0.1, 0.2, 0.3, ...]');



SELECT rowid, distance

FROM doc_embeddings

WHERE embedding MATCH '[0.15, 0.25, 0.35, ...]'

ORDER BY distance

LIMIT 5;

七、给技术决策者的建议

如果你正在为团队做向量检索的技术选型，我的建议非常务实：

第一步：从pgvector开始。如果你已经在使用PostgreSQL（大多数团队都是），那么pgvector是零成本起步的选择。安装扩展、建表、建索引，半天内就能跑通。在这个阶段不要纠结于理论性能差异。

第二步：用真实数据做基准测试。用你实际的向量数据和查询模式做压测。记录p50、p99延迟和召回率。大概率你会发现pgvector完全满足需求。

第三步：只有在pgvector确实不满足需求时，才引入专用向量数据库。而这个”不满足”需要有数据支撑——不是”我觉得可能不够快”，而是”我们的p99延迟超过了200ms，用户有明确投诉”。

第四步：即使需要专用引擎，优先考虑可自建的方案。Qdrant和Milvus都是开源的，可以自建部署。避免供应商锁定带来的成本失控。

结语：务实主义胜过技术崇拜

向量数据库赛道的泡沫正在消退，这不是坏事。它意味着行业正在回归理性——用最简单的工具解决问题，而不是为了追逐新技术而引入不必要的复杂性。

PostgreSQL吞噬向量数据库市场的故事，本质上是在提醒每一个技术决策者：当你看到一个火热的新技术品类时，先问自己一个问题——我现有的工具，加上一个扩展插件，能不能解决这个问题？如果答案是”能”，那么大概率那就是最优解。

毕竟，最好的基础设施，是你已经拥有的那一个。