文章目录pgvector 介绍让 PostgreSQL 拥有向量检索能力什么是 pgvector为什么 pgvector 会流行pgvector 的核心能力向量存储向量距离计算L2 Distance欧氏距离-Cosine DistanceInner Product内积#pgvector 的索引机制IVFFlatHNSW一个完整的 RAG 流程1. 文档切片2. 生成 embedding3. 写入 PostgreSQL4. 用户查询5. 相似度搜索6. 拼接 Prompt7. 发送给 LLMpgvector 与专业向量数据库的区别pgvector 的优势1. PostgreSQL 生态完整2. 数据一致性更简单3. 开发体验非常好pgvector 的局限性1. 超大规模场景不占优2. 内存压力明显3. Vacuum 与索引维护问题pgvector 的典型适用场景适合AI MVP中小规模 RAGAgent MemoryAI SaaS不适合的场景超大规模向量搜索极致低延迟召回GPU Vector Searchpgvector 常见技术栈PythonLangChainLlamaIndexDjangopgvector 的工程实践建议embedding 不要频繁更新尽量避免超高维度metadata 与 embedding 放一起合理选择索引一个容易被忽视的问题总结pgvector 介绍让 PostgreSQL 拥有向量检索能力在 AI 应用快速发展的今天向量数据库Vector Database几乎已经成为 RAG、语义搜索、推荐系统、AI Agent 的基础设施。但很多团队在真正落地时会遇到一个现实问题我已经有 PostgreSQL 了真的需要再引入一个新的向量数据库吗这也是 pgvector 出现并迅速流行的原因。pgvector 是 PostgreSQL 的一个扩展Extension它允许 PostgreSQL 原生存储向量并进行向量相似度搜索。它的核心价值并不是“性能超越专业向量数据库”而是降低架构复杂度避免数据同步利用 PostgreSQL 生态让 AI 能力自然融入现有业务系统本文将从架构、原理、索引、性能、适用场景等多个角度全面介绍 pgvector。什么是 pgvectorpgvector 是一个 PostgreSQL 扩展用于存储 embedding向量进行向量距离计算支持 ANNApproximate Nearest Neighbor近似最近邻搜索支持向量索引其官方项目pgvector GitHub安装后PostgreSQL 会新增一种数据类型vector例如CREATETABLEdocuments(id BIGSERIALPRIMARYKEY,contentTEXT,embedding VECTOR(1536));这里的1536对应 embedding 维度。如果你使用OpenAI text-embedding-3-smallOpenAI ada-002bge-largee5-large都需要根据实际维度定义字段。为什么 pgvector 会流行在 pgvector 出现之前很多 AI 系统架构是这样的应用层 │ ├── PostgreSQL业务数据 │ └── Pinecone / Milvus / Weaviate向量数据这会带来很多问题数据同步复杂一致性难维护运维成本增加需要维护额外集群查询逻辑分裂而 pgvector 的思路是PostgreSQL ├── 业务数据 └── 向量数据这样metadata 和 embedding 可以事务一致不需要额外同步 pipelineSQL 可以统一查询运维成本明显下降因此pgvector 非常适合AI MVP中小规模 RAG内部知识库Agent MemoryAI 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 DistanceCosine DistanceSELECT*FROMitemsORDERBYembedding[1,2,3]LIMIT5;运算符在 embedding 搜索中最常见。因为 embedding 更关注方向相似度而不是绝对长度。Inner Product内积#SELECT*FROMitemsORDERBYembedding# [1,2,3]LIMIT5;运算符#适合推荐系统normalized embeddingranking 模型pgvector 的索引机制如果没有索引ORDERBYembeddingquery_vector会变成全表扫描数据量稍微变大就无法接受。因此 pgvector 提供 ANN 索引。IVFFlatIVFFlat 是 pgvector 最早支持的 ANN 索引。创建方式CREATEINDEXONitemsUSINGivfflat(embedding vector_cosine_ops)WITH(lists100);其核心思想先聚类 再只搜索部分聚类过程类似所有向量 ↓ KMeans 聚类 ↓ 查询时只扫描最接近的几个 cluster优点查询速度快内存占用低缺点精度下降参数敏感数据更新频繁时效果会变差HNSW后来 pgvector 加入了 HNSW。这是目前更主流的方案。创建方式CREATEINDEXONitemsUSINGhnsw(embedding vector_cosine_ops);HNSW 全称Hierarchical Navigable Small World它本质是一种多层图结构查询时通过图导航快速逼近最近邻。其特点特性HNSW查询速度非常快Recall很高内存占用较高建索引时间较长动态更新较好如今MilvusWeaviateQdrantElasticsearch Vectorpgvector基本都支持 HNSW。一个完整的 RAG 流程下面是 pgvector 在 RAG 中的典型流程。1. 文档切片PDF → Chunk → embedding例如每 500 token 切一段2. 生成 embedding例如embeddingmodel.embed(text)得到[0.0182,-0.282,...]3. 写入 PostgreSQLINSERTINTOdocs(content,embedding)VALUES(...)4. 用户查询用户输入What is vector database?生成 query embedding。5. 相似度搜索SELECTcontentFROMdocsORDERBYembeddingquery_embeddingLIMIT5;6. 拼接 PromptContext: ... Question: ...7. 发送给 LLM最终生成回答。pgvector 与专业向量数据库的区别这是很多人最关心的问题。pgvector 的优势1. PostgreSQL 生态完整你可以直接使用JOINTransactionBackupReplicationPartitionJSONBRow Level Security这是巨大优势。很多专业向量数据库向量能力强。但事务能力、SQL 能力、生态成熟度远不如 PostgreSQL。2. 数据一致性更简单例如文章删除 embedding 自动一起删除不需要双写 消息队列同步 CDC3. 开发体验非常好开发者可以直接SELECT...ORDERBYembedding...不需要学习新的 Query DSLQuery Domain-Specific Language查询特定领域语言。pgvector 的局限性但 pgvector 也不是万能的。1. 超大规模场景不占优例如数亿 embeddingTB 级向量高 QPS ANN专业向量数据库通常更强。因为它们专门优化 ANN自定义存储引擎更激进的内存布局GPU 支持分布式 ANN而 PostgreSQL 本质仍是通用 OLTP联机事务处理 数据库2. 内存压力明显HNSW 很吃内存。embedding 本身也很大1536 dim × 4 bytes ≈ 6KB / vector在计算机中向量的每个维度即每个数值通常以 float32单精度浮点数格式存储而 float32 正好占用 4 个字节100 万条≈ 6GB还不包括索引metadataWALMVCCMulti-Version Concurrency Control多版本并发控制是一种数据库管理系统中常用的并发控制技术主要用于提高数据库的并发性能3. Vacuum 与索引维护问题PostgreSQL 的 MVCC 机制意味着UPDATEDELETE会产生 dead tuples。向量索引也需要维护。大量写入时vacuumreindexautovacuum tuning都需要认真调优。pgvector 的典型适用场景适合AI MVP这是 pgvector 最强场景。因为简单 极致性能中小规模 RAG例如公司知识库FAQAI 搜索文档助手Agent Memory例如长期记忆 对话检索 历史语义搜索AI SaaS尤其适合每租户数据量不大但租户很多的系统。因为 PostgreSQL 的多租户能力成熟。不适合的场景超大规模向量搜索例如10 亿 embedding高频 ANN实时推荐系统极致低延迟召回例如10ms ANN at huge scaleGPU Vector Searchpgvector 目前不属于 GPU-first 架构。pgvector 常见技术栈Python常见组合psycopgSQLAlchemyasyncpg例如frompgvector.psycopgimportregister_vectorLangChainLangChain 原生支持 pgvector。例如PGVectorLlamaIndex也支持Postgres Vector StoreDjango可直接VectorFieldpgvector 的工程实践建议embedding 不要频繁更新因为UPDATE 会导致索引维护通常delete insert更简单。尽量避免超高维度高维 embedding更占内存ANN 更慢很多时候768 dim已经足够。metadata 与 embedding 放一起这是 pgvector 最大价值之一。例如tenant_id document_id author tags created_at embedding可以直接WHEREtenant_id?再进行向量搜索。合理选择索引一般场景推荐小数据量不建索引中规模IVFFlat大规模HNSW一个容易被忽视的问题很多人以为向量数据库 AI其实并不是。embedding 检索只是信息召回它解决的是找到相关内容而不是理解内容因此RAG 的效果更多取决于chunkingembedding modelrerankprompt数据质量而不仅仅是你用了哪个向量数据库总结pgvector 的成功本质上不是因为它“最强”。而是因为它足够强同时足够简单它让 AI 系统可以复用 PostgreSQL降低系统复杂度快速构建 RAG保持事务一致性使用成熟 SQL 生态对于MVP中小规模 AI 系统SaaS 产品内部知识库pgvector 往往是一个极其务实的选择。但如果进入超大规模 ANN极限低延迟分布式 GPU 检索那么专业向量数据库仍然更具优势。因此真正重要的问题不是pgvector 好不好而是你的系统到底需要什么规模与复杂度这也是工程实践里最重要的一件事不要为了“未来可能的规模”过早引入复杂系统。