向量数据库、Elasticsearch 和 pgvector 到底该怎么选？

在做 RAG、语义搜索、推荐系统或者“长期记忆检索”这类 AI 应用时，很多人都会碰到一个很实际的问题：

到底该选专用向量数据库，还是 Elasticsearch，还是 PostgreSQL + pgvector？

这几个方案都能做向量检索，但它们的设计目标并不一样。很多时候，技术选型做错，不是因为某个产品“不够强”，而是因为场景和工具不匹配。

这篇文章就试着把这三类方案讲清楚：它们分别适合什么场景、各自的优缺点是什么，以及实际项目里到底该怎么选。

---

一、先说结论

如果你只想先记住一句话，可以记这个：

• 已有成熟搜索体系，强调关键词检索、过滤、排序、聚合：优先看 Elasticsearch

• 主数据已经在 PostgreSQL，想最小成本接入向量能力：优先看 pgvector

• 核心目标就是做大规模向量检索、RAG、推荐、AI 检索基础设施：优先看 专用向量数据库

换句话说：

pgvector 是“把向量带进数据库”
Elasticsearch 是“把向量带进搜索引擎”
专用向量数据库是“围绕向量检索来设计数据库”

看起来只是顺序不一样，实际上背后的产品哲学完全不同。

---

二、什么是“专用向量数据库”？

专用向量数据库，像 Pinecone、Weaviate、Milvus 这类产品，本质上就是专门围绕“向量存储 + 相似度搜索”设计的数据库。

它最擅长的事情是：

• 存 embedding

• 建立高性能向量索引

• 做近似最近邻搜索（ANN）

• 支持 metadata filter

• 支持大规模扩容

• 服务 RAG、推荐、语义召回、agent memory 这类 AI 场景

它的核心目标不是做事务，不是做复杂 SQL，也不是做全文搜索，而是：

如何更快、更准、更稳地找到“语义上最相似”的内容。

所以如果你的系统本质上是一个“AI 检索系统”，专用向量数据库往往最合适。

---

三、Elasticsearch：本质上还是搜索引擎

很多人现在也会用 Elasticsearch 来做向量搜索，这没有问题，因为它已经支持 dense vector、kNN search、hybrid search 等能力。

但要注意，Elasticsearch 首先是搜索引擎，然后才是带向量能力的搜索平台。

它最强的地方一直是这些：

• 倒排索引

• BM25 关键词检索

• 条件过滤

• 聚合分析

• 分面搜索

• 排序能力

• 搜索生态成熟

所以 Elasticsearch 特别适合下面这类场景：

• 商品搜索

• 站内搜索

• 文档搜索

• 日志搜索

• 企业搜索

• 搜索系统中叠加语义检索能力

Elasticsearch 的优势

它最大的优势，不是“向量检索最强”，而是：

关键词检索和语义检索可以天然融合。

比如用户搜一个商品、一个报错码、一个法规编号，里面既有精确匹配需求，也有语义理解需求。
这时候如果只用纯向量检索，往往不够稳。因为很多业务查询里，精确词项非常重要。

例如这些内容：

• SKU

• 产品型号

• 报错信息

• 法规条文编号

• 版本号

• 人名、地名、组织名

这些内容更适合关键词检索；而用户自然语言表达的“意思相近”，又更适合向量检索。
Elasticsearch 在这种 hybrid search（混合检索） 场景下就很顺手。

Elasticsearch 的局限

但另一方面，Elasticsearch 不是为向量检索“从零设计”的产品。

所以当你的核心诉求变成：

• 超大规模 embedding 检索

• 极低延迟 ANN

• AI 检索基础设施

• RAG 为中心的系统设计

• 以向量索引为主的能力扩展

那么 Elasticsearch 虽然也能做，但通常不是最“自然”的方案。

它更像是：

我本来就有一个强大的搜索平台，现在顺便把向量能力补上。

而不是：

我就是专门为向量检索服务的。

---

四、pgvector：最省事，但不是“最强向量平台”

pgvector 是 PostgreSQL 的一个向量扩展。

它的最大吸引力不在于“向量检索能力碾压别人”，而在于：

你不用额外引入一套新系统。

这件事在工程上非常重要。

因为很多团队的数据、本体业务、权限体系、事务模型，本来就都在 PostgreSQL 里。如果为了做一点语义搜索、相似推荐或者知识检索，就再引入一套专用向量库，系统复杂度会立刻上去。

而 pgvector 的思路非常直接：

• 数据还在 PostgreSQL

• 继续用 SQL

• 继续和业务表 JOIN

• 继续沿用备份、权限、运维体系

• 只是额外支持向量字段和相似度检索

这对很多中小团队来说，非常有吸引力。

pgvector 适合什么场景？

它特别适合这类场景：

• 数据主库本来就在 PostgreSQL

• 先做一个 RAG 原型

• 想低成本接入 embedding 检索

• 需要和业务数据紧密关联

• 团队不想马上维护额外基础设施

比如一个知识库系统，文档和权限都存在 PostgreSQL 里，这时候用 pgvector 非常顺手。
你可以直接把文档 chunk 和 embedding 一起存到数据库里，然后在查询时按用户权限过滤，再做向量召回。

pgvector 的问题在哪里？

pgvector 的问题不在于“不能用”，而在于它本质上仍然是：

PostgreSQL 里的向量能力，而不是一个以向量检索为核心设计的数据库系统。

所以当你面临以下问题时，复杂度会逐渐上升：

• 向量数据量很大

• 写入频繁

• 并发检索压力高

• 索引调优变复杂

• 检索性能越来越敏感

• 需要更多面向 AI 的原生能力

这时候，虽然 PostgreSQL 也能扛，但你会发现自己要做越来越多的工程优化，比如：

• 分区

• 索引策略调整

• 参数调优

• 检索和写入的平衡

• SQL 层面的复杂优化

也就是说，pgvector 很适合“快速起步”和“中小规模场景”，但未必适合所有大规模 AI 检索场景。

---

五、三者的本质差异到底是什么？

如果从产品定位来讲，三者最核心的区别在于：它们想优化的目标不同。

1. pgvector 优化的是“系统简单性”

它想解决的问题是：

我已经有 PostgreSQL 了，能不能别再引入一套新系统？

所以它非常强调：

• 低接入成本

• 数据一体化

• SQL 兼容

• 业务集成方便

2. Elasticsearch 优化的是“搜索能力完整性”

它想解决的问题是：

我已经有很强的搜索系统了，能不能把语义搜索也纳入进来？

所以它非常强调：

• 倒排索引

• BM25

• 过滤

• 聚合

• 排序

• 混合检索

3. 专用向量数据库优化的是“向量检索本身”

它想解决的问题是：

如何把向量检索做成 AI 时代的基础设施？

所以它更强调：

• 大规模向量索引

• ANN 性能

• 扩缩容

• 向量检索体验

• AI / RAG 场景适配

---

六、实际项目里怎么选？

下面直接给一个更实用的选型建议。

场景 1：你的业务数据库就是 PostgreSQL

如果你的业务数据、权限数据、文档数据、用户数据，本来全都在 PostgreSQL 中，而且当前规模不算特别夸张，那么最推荐的第一步通常是：

先用 pgvector。

理由很简单：

• 成本最低

• 上手最快

• 架构改动最小

• 最容易验证业务价值

很多团队其实不是一开始就需要“最强的向量基础设施”，而是先需要一个能跑起来的版本。
在这种情况下，pgvector 往往是最合理的起点。

---

场景 2：你已经有 Elasticsearch 搜索体系

如果你本来就有 Elasticsearch，比如已经在做：

• 电商搜索

• 内容搜索

• 日志平台

• 企业搜索

• 站内检索

那通常最自然的路线不是新引入一个向量数据库，而是：

优先在 Elasticsearch 体系里补上向量检索能力。

因为你已经拥有：

• 关键词搜索

• 过滤

• 排序

• 聚合

• 权限控制

• 搜索运维经验

这时候再加上 dense vector 和 hybrid search，性价比往往非常高。

---

场景 3：你做的是 RAG / 推荐 / AI 检索平台

如果你的系统从一开始就是围绕这些需求构建的：

• RAG

• 推荐系统

• 语义召回

• agent memory

• 多模态相似检索

• AI 知识基础设施

并且你预期未来会有：

• 大规模 embedding 数据

• 高并发检索

• 更复杂的检索链路

• 更强的扩展需求

那么更推荐：

直接上专用向量数据库。

这类产品的设计目标和你的问题更贴合，后续演进成本也往往更低。

---

七、一个非常实用的判断方法

如果你还在纠结，可以用下面这组问题来判断。

优先选 pgvector，如果你符合这些特点：

• 业务系统已经在 PostgreSQL

• 想快速上线

• 团队规模不大

• 先做 MVP

• 向量检索只是业务的一部分，不是全部核心

优先选 Elasticsearch，如果你符合这些特点：

• 已有成熟 ES 搜索栈

• 查询中有大量关键词、编号、版本、SKU

• 很依赖过滤、聚合、排序

• 想做 keyword + semantic 的混合检索

优先选专用向量数据库，如果你符合这些特点：

• AI 检索是系统核心

• 数据量大

• 需要高性能 ANN

• 需要独立扩容

• 想把向量检索能力平台化、基础设施化

---

八、总结

最后，用一句话总结这三者的区别：

pgvector 解决的是“最小成本接入向量能力”
Elasticsearch 解决的是“在完整搜索体系中加入语义检索”
专用向量数据库解决的是“把向量检索做成核心基础设施”

所以，真正该问的问题不是“谁更强”，而是：

你的系统，究竟是数据库系统、搜索系统，还是 AI 检索系统？

这个问题想清楚了，选型基本也就清楚了。