pgvector介绍（PostgreSQL扩展，允许PG原生存储向量，并进行向量相似度搜索）向量距离计算、欧氏距离、内积、ANN索引、IVFFlat、HNSW、Query DSL

pgvector 介绍：让 PostgreSQL 拥有向量检索能力

在 AI 应用快速发展的今天，向量数据库（Vector Database）几乎已经成为 RAG、语义搜索、推荐系统、AI Agent 的基础设施。

但很多团队在真正落地时，会遇到一个现实问题：

我已经有 PostgreSQL 了，真的需要再引入一个新的向量数据库吗？

这也是 pgvector 出现并迅速流行的原因。

pgvector 是 PostgreSQL 的一个扩展（Extension），它允许 PostgreSQL 原生存储向量，并进行向量相似度搜索。

它的核心价值并不是“性能超越专业向量数据库”，而是：

• 降低架构复杂度
• 避免数据同步
• 利用 PostgreSQL 生态
• 让 AI 能力自然融入现有业务系统

本文将从架构、原理、索引、性能、适用场景等多个角度，全面介绍 pgvector。

什么是 pgvector

pgvector 是一个 PostgreSQL 扩展，用于：

• 存储 embedding（向量）
• 进行向量距离计算
• 支持 ANN（Approximate Nearest Neighbor）近似最近邻搜索
• 支持向量索引

其官方项目：

pgvector GitHub

安装后，PostgreSQL 会新增一种数据类型：

vector

例如：

CREATETABLEdocuments(id BIGSERIALPRIMARYKEY,contentTEXT,embedding VECTOR(1536));

这里的1536对应 embedding 维度。

如果你使用：

• OpenAI text-embedding-3-small
• OpenAI ada-002
• bge-large
• e5-large

都需要根据实际维度定义字段。

为什么 pgvector 会流行

在 pgvector 出现之前，很多 AI 系统架构是这样的：

应用层 │ ├── PostgreSQL（业务数据） │ └── Pinecone / Milvus / Weaviate（向量数据）

这会带来很多问题：

• 数据同步复杂
• 一致性难维护
• 运维成本增加
• 需要维护额外集群
• 查询逻辑分裂

而 pgvector 的思路是：

PostgreSQL ├── 业务数据 └── 向量数据

这样：

• metadata 和 embedding 可以事务一致
• 不需要额外同步 pipeline
• SQL 可以统一查询
• 运维成本明显下降

因此：

pgvector 非常适合：

• AI MVP
• 中小规模 RAG
• 内部知识库
• Agent Memory
• AI SaaS 产品

pgvector 的核心能力

向量存储

最基础能力：

VECTOR(n)

例如：

VECTOR(768)VECTOR(1536)VECTOR(3072)

底层本质是：

float4[]

即：

[0.123, -0.482, 0.998, ...]

向量距离计算

pgvector 支持多种距离函数。

L2 Distance（欧氏距离）（<->）

SELECT*FROMitemsORDERBYembedding<->'[1,2,3]'LIMIT5;

运算符：

<->

表示：

Euclidean Distance

Cosine Distance（<=>）

SELECT*FROMitemsORDERBYembedding<=>'[1,2,3]'LIMIT5;

运算符：

<=>

在 embedding 搜索中最常见。

因为 embedding 更关注方向相似度，而不是绝对长度。

Inner Product（内积）（<#>）

SELECT*FROMitemsORDERBYembedding<#> '[1,2,3]'LIMIT5;

运算符：

<#>

适合：

• 推荐系统
• normalized embedding
• ranking 模型

pgvector 的索引机制

如果没有索引：

ORDERBYembedding<=>query_vector

会变成：

全表扫描

数据量稍微变大就无法接受。

因此 pgvector 提供 ANN 索引。

IVFFlat

IVFFlat 是 pgvector 最早支持的 ANN 索引。

创建方式：

CREATEINDEXONitemsUSINGivfflat(embedding vector_cosine_ops)WITH(lists=100);

其核心思想：

先聚类 再只搜索部分聚类

过程类似：

所有向量 ↓ KMeans 聚类 ↓ 查询时只扫描最接近的几个 cluster

优点：

• 查询速度快
• 内存占用低

缺点：

• 精度下降
• 参数敏感
• 数据更新频繁时效果会变差

HNSW

后来 pgvector 加入了 HNSW。

这是目前更主流的方案。

创建方式：

CREATEINDEXONitemsUSINGhnsw(embedding vector_cosine_ops);

HNSW 全称：

Hierarchical Navigable Small World

它本质是一种：

多层图结构

查询时通过图导航快速逼近最近邻。

其特点：

如今：

• Milvus
• Weaviate
• Qdrant
• Elasticsearch Vector
• pgvector

基本都支持 HNSW。

一个完整的 RAG 流程

下面是 pgvector 在 RAG 中的典型流程。

1. 文档切片

PDF → Chunk → embedding

例如：

每 500 token 切一段

2. 生成 embedding

例如：

embedding=model.embed(text)

得到：

[0.0182,-0.282,...]

3. 写入 PostgreSQL

INSERTINTOdocs(content,embedding)VALUES(...)

4. 用户查询

用户输入：

What is vector database?

生成 query embedding。

5. 相似度搜索

SELECTcontentFROMdocsORDERBYembedding<=>query_embeddingLIMIT5;

6. 拼接 Prompt

Context: ... Question: ...

7. 发送给 LLM

最终生成回答。

pgvector 与专业向量数据库的区别

这是很多人最关心的问题。

pgvector 的优势

1. PostgreSQL 生态完整

你可以直接使用：

• JOIN
• Transaction
• Backup
• Replication
• Partition
• JSONB
• Row Level Security

这是巨大优势。

很多专业向量数据库：

向量能力强。

但事务能力、SQL 能力、生态成熟度远不如 PostgreSQL。

2. 数据一致性更简单

例如：

文章删除 embedding 自动一起删除

不需要：

双写 消息队列同步 CDC

3. 开发体验非常好

开发者可以直接：

SELECT...ORDERBYembedding<=>...

不需要学习新的 Query DSL（Query Domain-Specific Language，查询特定领域语言）。

pgvector 的局限性

但 pgvector 也不是万能的。

1. 超大规模场景不占优

例如：

• 数亿 embedding
• TB 级向量
• 高 QPS ANN

专业向量数据库通常更强。

因为它们：

• 专门优化 ANN
• 自定义存储引擎
• 更激进的内存布局
• GPU 支持
• 分布式 ANN

而 PostgreSQL 本质仍是：

通用 OLTP（联机事务处理） 数据库

2. 内存压力明显

HNSW 很吃内存。

embedding 本身也很大：

1536 dim × 4 bytes ≈ 6KB / vector

（在计算机中，向量的每个维度（即每个数值）通常以 float32（单精度浮点数）格式存储，而 float32 正好占用 4 个字节）

100 万条：

≈ 6GB

还不包括：

• 索引
• metadata
• WAL
• MVCC（Multi-Version Concurrency Control，多版本并发控制，是一种数据库管理系统中常用的并发控制技术，主要用于提高数据库的并发性能）

3. Vacuum 与索引维护问题

PostgreSQL 的 MVCC 机制意味着：

• UPDATE
• DELETE

会产生 dead tuples。

向量索引也需要维护。

大量写入时：

• vacuum
• reindex
• autovacuum tuning

都需要认真调优。

pgvector 的典型适用场景

适合

AI MVP

这是 pgvector 最强场景。

因为：

简单 > 极致性能

中小规模 RAG

例如：

• 公司知识库
• FAQ
• AI 搜索
• 文档助手

Agent Memory

例如：

长期记忆 对话检索 历史语义搜索

AI SaaS

尤其适合：

每租户数据量不大

但：

租户很多

的系统。

因为 PostgreSQL 的多租户能力成熟。

不适合的场景

超大规模向量搜索

例如：

• 10 亿 embedding
• 高频 ANN
• 实时推荐系统

极致低延迟召回

例如：

<10ms ANN at huge scale

GPU Vector Search

pgvector 目前不属于 GPU-first 架构。

pgvector 常见技术栈

Python

常见组合：

• psycopg
• SQLAlchemy
• asyncpg

例如：

frompgvector.psycopgimportregister_vector

LangChain

LangChain 原生支持 pgvector。

例如：

PGVector

LlamaIndex

也支持：

Postgres Vector Store

Django

可直接：

VectorField

pgvector 的工程实践建议

embedding 不要频繁更新

因为：

UPDATE 会导致索引维护

通常：

delete + insert

更简单。

尽量避免超高维度

高维 embedding：

• 更占内存
• ANN 更慢

很多时候：

768 dim

已经足够。

metadata 与 embedding 放一起

这是 pgvector 最大价值之一。

例如：

tenant_id document_id author tags created_at embedding

可以直接：

WHEREtenant_id=?

再进行向量搜索。

合理选择索引

一般：

一个容易被忽视的问题

很多人以为：

向量数据库 = AI

其实并不是。

embedding 检索只是：

信息召回

它解决的是：

找到相关内容

而不是：

理解内容

因此：

RAG 的效果更多取决于：

• chunking
• embedding model
• rerank
• prompt
• 数据质量

而不仅仅是：

你用了哪个向量数据库

总结

pgvector 的成功，本质上不是因为它“最强”。

而是因为：

它足够强，同时足够简单

它让 AI 系统可以：

• 复用 PostgreSQL
• 降低系统复杂度
• 快速构建 RAG
• 保持事务一致性
• 使用成熟 SQL 生态

对于：

• MVP
• 中小规模 AI 系统
• SaaS 产品
• 内部知识库

pgvector 往往是一个极其务实的选择。

但如果进入：

• 超大规模 ANN
• 极限低延迟
• 分布式 GPU 检索

那么专业向量数据库仍然更具优势。

因此：

真正重要的问题不是：

pgvector 好不好

而是：

你的系统到底需要什么规模与复杂度

这也是工程实践里最重要的一件事：

不要为了“未来可能的规模”，过早引入复杂系统。