2290 字
11 分钟
向量数据库 2026 大洗牌:pgvector 崛起,独立向量库何去何从?

向量数据库市场正在「回归传统」#

兄弟们,如果你 2024 年问我「做 RAG 用什么向量数据库」,我会毫不犹豫地说 Pinecone 或者 Qdrant。但站在 2026 年回头看,这个答案已经变了。

市场正在经历一次大规模的整合。简单说就是——传统关系型数据库把向量搜索功能直接吞了,而且吞得很彻底。

先说个震撼点的数据:PostgreSQL 的 pgvectorscale 扩展在 50M 向量的 COSINE 搜索 benchmark 上,跑出了 471 QPS,而 Qdrant 在同规模下只有 41 QPS,而且 pgvectorscale 能做到 99% 的召回率。差了整整 11 倍,这已经不是「能打」的问题了,是「根本不需要独立的向量数据库了」。

pgvector 的正确打开方式#

-- 在 PostgreSQL 16+ 中启用 pgvector 和 pgvectorscale
CREATE EXTENSION IF NOT EXISTS vector;
CREATE EXTENSION IF NOT EXISTS vectorscale;
-- StreamingDiskANN 索引:2026 年 pgvector 的杀手锏
CREATE INDEX idx_docs_embedding_streaming_diskann
ON documents USING diskann (embedding vector_cosine_ops)
WITH (max_retries = 3);
-- 混合搜索:向量相似度 + SQL 条件过滤
SELECT
id,
title,
content,
embedding <=> $1::vector AS cosine_distance
FROM documents
WHERE
category = 'cardiology' -- 传统 SQL 过滤
AND published_at > '2025-01-01'
AND embedding <=> $1::vector < 0.5 -- 向量相似度阈值
ORDER BY embedding <=> $1::vector
LIMIT 20;

这个 SQL 把向量搜索和传统的关系查询融合在了一起。以前你要做「在心脏病学分类下找语义相似的文章」,需要两套系统——PostgreSQL 查分类,Pinecone 查向量,中间还得写胶水代码同步数据。现在一句 SQL 搞定,还带事务保证。

为什么独立向量数据库的位置越来越尴尬?#

2024-2025 年的时候,大家的典型架构是这样的:

应用代码 → LangChain → Pinecone(向量搜索)+ PostgreSQL(业务数据)
↘ 手动同步数据(要么双写,要么 CDC 管道)

这个架构有几个痛点:

数据一致性问题:你在 PostgreSQL 里更新了一篇文章,如果向量数据库没同步,搜索出来的就是过期数据。CDC 管道(Debezium + Kafka + 向量数据库写入器)可以解决这个问题,但运维成本极高。

运维复杂度:两套数据库,两套监控,两套备份策略,两套扩容方案——成本几乎是翻倍的。

查询能力受限:Pinecone 不支持复杂的结构化过滤。你要做「找最近 7 天内、浏览量 > 1000 的、和这篇内容语义相似的、而且不要我昨天已经看过的文章」——这种需求在独立向量数据库里基本不可能实现。

# 2026 年的推荐方案:全部用 PostgreSQL
import psycopg2
from sentence_transformers import SentenceTransformer
# 加载轻量级 embedding 模型
model = SentenceTransformer("BAAI/bge-small-en-v1.5")
def hybrid_search(query: str, category: str, limit: int = 10):
embedding = model.encode(query).tolist()
conn = psycopg2.connect(
host="localhost",
dbname="blog",
user="app_user"
)
# 一次查询搞定全部
with conn.cursor() as cur:
cur.execute("""
SELECT
d.id, d.title, d.content,
1 - (d.embedding <=> %s::vector) AS similarity,
d.view_count,
d.published_at
FROM documents d
WHERE
d.category = %s
AND d.published_at > NOW() - INTERVAL '7 days'
AND d.embedding <=> %s::vector < 0.4
ORDER BY d.embedding <=> %s::vector
LIMIT %s
""", (embedding, category, embedding, embedding, limit))
results = cur.fetchall()
conn.close()
return results
# 用起来
articles = hybrid_search(
query="什么是 RAG 的最佳实践?",
category="AI",
limit=5
)

十五行代码,一个函数,一个数据库连接,全部搞定。不需要 LangChain、不需要向量数据库客户端、不需要同步管道。这就是 2026 年向量搜索的最佳实践。

什么时候仍然需要独立向量数据库?#

当然,我也不会说独立向量数据库完全没用。在以下场景它们仍然有优势:

┌─────────────────┬─────────────────────┬─────────────────────┐
│ 场景 │ 推荐方案 │ 原因 │
├─────────────────┼─────────────────────┼─────────────────────┤
│ < 50M 向量 │ pgvector │ 简单、一致性保证 │
│ 50M-500M 向量 │ Qdrant / Milvus │ 分布式索引性能更强 │
│ > 1B 向量 │ Milvus │ 原生分布式分片 │
│ 超低延迟 <10ms │ Redis + vector │ 纯内存,延迟最低 │
│ 原型/PoC │ Chroma │ 零配置,快速验证 │
│ 离线/边缘设备 │ LanceDB │ 嵌入式,无服务端 │
└─────────────────┴─────────────────────┴─────────────────────┘

如果你的应用已经用了 PostgreSQL(大多数项目都这样),向量数量在 5000 万以下,直接用 pgvector+pgvectorscale 就够了。别再引入额外的中间件和同步管道了,维护两套数据库的痛苦,谁经历谁知道。

2026 年的 RAG 架构长什么样?#

Terminal window
# 用 Docker Compose 一键启动一个完整的 RAG 服务
cat > docker-compose.yml << 'EOF'
version: "3.9"
services:
postgres:
image: pgvector/pgvector:pg16
environment:
POSTGRES_DB: ragdb
POSTGRES_USER: app
POSTGRES_PASSWORD: ${DB_PASSWORD}
volumes:
- pgdata:/var/lib/postgresql/data
ports:
- "5432:5432"
embedding:
image: ghcr.io/huggingface/text-embeddings-inference:1.5
environment:
MODEL: BAAI/bge-large-en-v1.5
API_KEY: ${HF_TOKEN}
ports:
- "8080:80"
app:
build: .
environment:
DATABASE_URL: postgres://app:${DB_PASSWORD}@postgres:5432/ragdb
EMBEDDING_URL: http://embedding:80
ports:
- "3000:3000"
depends_on:
- postgres
- embedding
volumes:
pgdata:
EOF

pgvector vs 专用向量数据库:2026 年的选型决策树#

选择用 pgvector 还是专用向量数据库,其实取决于你的具体场景。我总结了一个简单的决策树:

开始:你的应用需要向量搜索吗?
├── 你的数据量 < 5000 万向量?
│ ├── 你已经用 PostgreSQL 了吗?
│ │ ├── ✅ → 直接用 pgvector + pgvectorscale(无脑选)
│ │ └── ❌ → 还是可以选 pgvector,迁移成本值得
│ │
├── 你的数据量 5000 万 - 5 亿向量?
│ ├── 你需要复杂 SQL 过滤吗?
│ │ ├── ✅ → pgvector(DiskANN)+ 分片
│ │ └── ❌ → Qdrant / Milvus
│ │
├── 你的数据量 > 5 亿向量?
│ └── → Milvus(原生分布式)
└── 延迟要求 < 10ms p99?
└── → Redis + Vector Search

这个决策树不是我随便画的,而是基于大量的实测数据。很多团队在 2024-2025 年选了专用向量数据库,到了 2026 年发现维护两套数据库的成本太高,又要迁回 pgvector。

向量数据库的 FinOps 对比#

说到成本,我们来看一个实际的账单对比。假设你有 1000 万向量,每日查询量 10 万次,向量维度 768(对应 text-embedding-3-small 的输出):

# 成本估算脚本
options = [
{
"name": "pgvector (自托管, 2×r6g.xlarge)",
"monthly_compute": "$186 × 2 = $372",
"monthly_storage": "$0.08/GB × 50GB = $4",
"monthly_total": "$376",
"notes": "已包含在现有 PostgreSQL 实例中,无需额外节点"
},
{
"name": "Pinecone (p2.x1, 1000 万向量)",
"monthly_compute": "$0.154/小时 × 730h = $112",
"monthly_storage": "~$70 (1000 万向量)",
"monthly_total": "$182",
"notes": "全托管,但超出免费额度后增长较快"
},
{
"name": "Qdrant (自托管, 3×c6i.xlarge)",
"monthly_compute": "$248 × 3 = $744",
"monthly_storage": "$0.08/GB × 80GB = $6.40",
"monthly_total": "$750",
"notes": "三节点集群,高可用"
},
{
"name": "Milvus (自托管, 3×m6i.xlarge)",
"monthly_compute": "$310 × 3 = $930",
"monthly_storage": "$0.08/GB × 100GB = $8",
"monthly_total": "$938",
"notes": "含 Query Node + Index Node + Data Node"
}
]
for opt in options:
print(f"{opt['name']}:")
print(f" 月成本: {opt['monthly_total']}")
print(f" 备注: {opt['notes']}")
print()

看到那个 376pgvector自托管方案了吗?这通常是你现有PostgreSQL实例上多花的一点点资源,不需要额外部署、不需要额外的运维人员、不需要额外的监控告警。而Pinecone376 的 pgvector 自托管方案了吗?**这通常是你现有 PostgreSQL 实例上多花的一点点资源**,不需要额外部署、不需要额外的运维人员、不需要额外的监控告警。而 Pinecone 的 182 看起来便宜,但那是独立账单,而且数据一致性、跨区域的同步成本都没算进去。

混合搜索的实战:推荐系统#

最后,我想用一个实际的推荐系统例子来展示 pgvector 在 2026 年的强大能力。假设你在做一个内容推荐平台,需要根据用户的阅读历史、偏好分类、时效性来做个性化推荐:

-- 2026 年的混合推荐查询
-- 需求:推荐「用户喜欢的、最近 7 天内的、和当前文章语义相似的、用户没看过的」文章
WITH user_profile AS (
-- 获取用户偏好向量和行为数据
SELECT
u.embedding AS user_preference_vector,
array_agg(DISTINCT h.article_id) AS read_articles,
u.preferred_categories
FROM users u
JOIN read_history h ON h.user_id = u.id
WHERE u.id = 42
AND h.read_at > NOW() - INTERVAL '30 days'
GROUP BY u.id
),
candidates AS (
SELECT
a.id,
a.title,
a.embedding <=> up.user_preference_vector AS relevance_score,
a.popularity_score,
a.published_at,
a.category
FROM articles a
CROSS JOIN user_profile up
WHERE
a.published_at > NOW() - INTERVAL '7 days' -- 时效性
AND a.category = ANY(up.preferred_categories) -- 偏好分类
AND a.id NOT IN (SELECT unnest(up.read_articles)) -- 去重
AND a.embedding <=> up.user_preference_vector < 0.6 -- 语义阈值
)
SELECT
id,
title,
category,
(1 - relevance_score) * 0.6 +
(popularity_score / 100) * 0.2 +
CASE
WHEN published_at > NOW() - INTERVAL '1 day' THEN 0.2
WHEN published_at > NOW() - INTERVAL '3 days' THEN 0.1
ELSE 0.05
END AS final_score
FROM candidates
ORDER BY final_score DESC
LIMIT 20;

这个查询融合了向量相似度 × 用户偏好 × 时效性 × 流行度 × 去重五个维度,全部在一个数据库、一个连接、一个 SQL 里完成。如果用 Pinecone + PostgreSQL 的两套方案,你需要:

  1. 查 PostgreSQL 获取用户画像
  2. 查 Pinecone 获取向量相似结果
  3. 手动过滤已读文章
  4. 重新排序合并分数
  5. 保证两边的数据一致性

复杂度不是一个量级的。

总结#

2026 年的向量数据库市场已经明确:pgvector 是大多数团队的最优选。除非你的向量规模在 5000 万以上,或者有超低延迟的硬性要求,否则一个 PostgreSQL + pgvectorscale + DiskANN 索引的组合已经足够了。

记住一句话:多一套数据库,多一份痛苦。能少用一个中间件就少用一个——少一个组件,少一个故障点,少一份运维账单。

2026 年选择向量数据库的正确思路不是「哪个向量数据库最好」,而是「我能不能不引入新的数据库」——答案在绝大多数情况下都是

向量数据库 2026 大洗牌:pgvector 崛起,独立向量库何去何从?
https://www.oferry.com/posts/a125/
作者
晨平安
发布于
2026-06-03
许可协议
CC BY-NC-SA 4.0
封面
示例歌曲
示例艺术家
封面
示例歌曲
示例艺术家
0:00 / 0:00