什么是 vector database?你真的需要吗?

Vector database 是专门存储与搜索高维向量的系统 — 也就是 AI 模型产出的 embedding。它是任何 RAG、语义搜索、推荐系统的存储层。「你需要 vector DB」这句话有道理,但专门 vector DB 跟「Postgres 装 pgvector」之间的取舍,比营销文案复杂得多。

Vector DB 在做什么

核心工作:给定几百万个向量,快速找出最接近某个查询向量的 K 个。

暴力法是 O(n) — 把查询跟每个存好的向量比一次。1 万条 OK(毫秒),100 万条很痛苦(秒级),1 亿条完全不可行。

Vector DB 用 approximate nearest neighbor(ANN) 索引 — 通常是 HNSW(Hierarchical Navigable Small World)或 IVF(Inverted File Index) — 达到次线性搜索。牺牲一点点精度(1-5% 的概率错过真正最近的邻居)换大幅加速。对语义搜索来说,这个取舍几乎永远值得。

搜索之外,现代 vector DB 还提供:

Metadata 过滤 — 「找相似向量,且 category = 'docs' 而且 updated_at > 2025-01-01」
Hybrid 搜索 — 把向量相似度跟关键字(BM25)分数结合
Multi-tenancy — 依用户/团队/workspace 隔离向量
接 reranker — top-K 丢给 reranker 模型重排
持久化与备份 — 持久存储、副本

2026 年的选项

大致分三群:

Postgres extension:

pgvector — 默认选项。Open source,任何 Postgres 都能装(包括 Supabase、Neon、RDS)。约 1000 万条内舒适。跟 app 数据同一个 DB,免分开运维。
pgvectorscale — Timescale 在 pgvector 之上的扩展,加 StreamingDiskANN 索引,可到十亿级。

专门 managed:

Pinecone — 云端 vector DB 元老,成熟、可扩到十亿,$70/mo 起。
Weaviate Cloud — 开源核心 + managed,schema 模块化。
Qdrant Cloud — Rust 写的、快、免费额度大方。
Milvus / Zilliz Cloud — 大规模、复杂些。

嵌入式 / 轻量:

Chroma — Python 嵌入式库,开发友好。Prototype 好,production 比较弱。
DuckDB / SQLite 向量扩展 — 嵌入式、单文件、适合离线或 edge。
LanceDB — 列式向量存储,扫描快,热度上升中。

怎么真的挑

大多数人适用的决策树:

**刚起步、向量 < 1000 万、已经用 Postgres?**用 pgvector。一个 DB、ship 快、大多数 app 不会超出。
**要 5000 万以上向量、严格延迟 SLA、零运维预算?**用 Pinecone 或 Qdrant Cloud。
**全部自架、要开源?**Qdrant 或 Weaviate。
**Edge、mobile、local-first?**SQLite 向量扩展或 LanceDB。
**在 Python 里 prototype?**Chroma 摩擦最少。

Over-engineering 陷阱:第一次做 RAG 的创始人挑 Pinecone 因为它「AI-native」,后来发现自己的 app 用同一个 Postgres + pgvector 还更简单。多数人第二个月就后悔。

真实性能数字

设定一下期待(2026 世代硬件):

Supabase Pro 上 pgvector + HNSW,10 万条 1,536 维向量:p95 查询延迟 5-20ms,月 $25(Supabase 方案,不是 vector DB 本身的钱)。
同硬件下 1000 万条:p95 30-100ms。
Pinecone serverless 1000 万条:p95 20-50ms,月 $70-200(看用量)。
$20/mo VPS 自架 Qdrant:10 万条 → 2-10ms。

规律:pgvector 对 ~95% 的 app 已经够快,差距只在规模或严格 SLA 才出现。

Metadata 问题

常见坑:embed 完文档、放进 vector DB,才发现要按 tenant_id、created_at、category 过滤。有些 vector DB 处理得优雅,有些不。

pgvector 继承 Postgres 完整 SQL:任何 WHERE 都能用。Metadata 故事最强。
Pinecone、Qdrant、Weaviate:各有 metadata filter 语法,常常微微受限。
Chroma:简单 metadata 过滤,基本案例 OK。

如果你的检索需要结构化过滤、不只是「top-K 向量 + 没 constraint」,pgvector 通常赢。

什么时候根本不用 vector DB

**文档 < 1,000 份。**完全跳过 vector store。请求时实时 embed + 内存暴力比、或全部塞进 LLM context window。
**查询主要是完全匹配。**用 Postgres FTS(全文搜索)或 BM25,向量是大炮打蚊子。
**数据能塞进 RAM、永远很小。**Python dict + numpy.argmax 有时候就是正解。
**还没撞到「检索质量」的墙。**如果瓶颈是切块不对或 embedding 模型错,换更花哨的 DB 也救不了。

迁移成本

实务考量:换 vector DB 烦但不致命。通常不必重 embed — 把向量 + metadata 导出,导入新 DB。大多数团队会在规模逼到时做一次。先用 pgvector 起步、有需要再迁,不要预先优化。