汤不热吧过去三年，向量数据库赛道堪称AI浪潮中最火热的细分领域之一。Pinecone拿到了红杉领投的1.38亿美元融资，Weaviate募资5000万美元，Milvus背后的Zilliz更是拿下了超过1亿美元的投资。一时间，似乎每个做AI应用的团队都需要一个专用向量数据库来存储和检索embedding。
但进入2026年，风向正在悄然改变。越来越多的团队发现，他们花大力气引入的专用向量数据库，带来的收益远不如预期——而PostgreSQL的一个扩展插件pgvector，正在悄无声息地吞噬这个市场。
一、专用向量数据库的崛起逻辑
要理解这场变革，先要回顾专用向量数据库为什么会火起来。2022年底ChatGPT发布后，RAG（检索增强生成）成为AI应用最主流的落地模式。核心思路很简单：把文档切块、做embedding、存入向量数据库，用户提问时用向量相似度搜索找到最相关的片段，再喂给大模型生成回答。
这个流程听起来简单，但工程实现上有一个关键瓶颈：传统关系型数据库并不擅长高维向量的相似度搜索。一个1536维的embedding做余弦相似度计算，在百万级数据量下如果用暴力扫描，延迟可能达到秒级，完全无法满足实时检索的需求。
专用向量数据库的核心卖点就在于此——它们内置了ANN（近似最近邻）算法，比如HNSW（分层可导航小世界图）和IVF（倒排文件），可以在百万甚至亿级向量中实现毫秒级检索：
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
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.1.0 | 2021年4月 | 基础向量类型，仅支持暴力扫描 |
| 0.4.0 | 2023年2月 | 引入IVFFlat索引，首次支持ANN |
| 0.5.0 | 2023年8月 | 引入HNSW索引，性能大幅提升 |
| 0.7.0 | 2024年3月 | 支持并行索引构建，halfvec类型 |
| 0.8.0 | 2025年1月 | 量化压缩、迭代式索引过滤 |
到了0.5.0版本引入HNSW索引后，pgvector的性能已经足以在大多数场景下与专用向量数据库掰手腕。在百万级向量、1536维的场景下，pgvector的p99查询延迟可以稳定在50ms以内，与Pinecone等托管服务的差距已经缩小到可以忽略的程度。
更关键的是，pgvector让你在PostgreSQL内完成一切——向量存储、相似度搜索、元数据过滤、事务一致性，全部用SQL搞定：
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和独立社区的测试），大致的结论如下：
| 数据规模 | pgvector (HNSW) | 专用向量DB | 差距 | 适用场景 |
|---|---|---|---|---|
| 10万向量 | ~2ms | ~1ms | 可忽略 | pgvector完胜 |
| 100万向量 | ~15ms | ~8ms | 微小 | pgvector足够 |
| 1000万向量 | ~80ms | ~30ms | 明显 | 看延迟要求 |
| 1亿向量以上 | 需要分片 | 原生支持 | 巨大 | 专用引擎更优 |
现实是，绝大多数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可能是最轻量的选择，不需要任何额外的网络服务。
2
3
4
5
6
7
8
9
10
11
12
13
14
15
.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吞噬向量数据库市场的故事，本质上是在提醒每一个技术决策者：当你看到一个火热的新技术品类时，先问自己一个问题——我现有的工具，加上一个扩展插件，能不能解决这个问题？如果答案是”能”，那么大概率那就是最优解。
毕竟，最好的基础设施，是你已经拥有的那一个。
