一句话定义：pgvector 是 PostgreSQL 的一款开源扩展（extension），它给 Postgres 加上了向量（vector）数据类型、距离运算符和索引，让你在原本存订单、用户、文章的那张库里，直接做"找相似"的检索。
它到底解决了什么
做语义搜索或 RAG（Retrieval-Augmented Generation，AI 词典：检索增强生成">检索增强生成）时，第一步是把文字、图片用嵌入模型（embedding model）转成一串浮点数，比如 1536 个数字，这就是一个向量。语义越接近的内容，向量在空间里的方向越接近。所谓"检索"，就是找出离查询向量最近的几条记录。
在 pgvector 出现前，常见做法是把向量单独灌进一个专用向量数据库（vector database）。打个比方：你本来只是想在自家厨房榨杯果汁，却专门盖了一间厂房、再养一头牛。pgvector 相当于在原有厨房里加一台榨汁机——数据不搬家，多加一列 vector 就行：
```sql
SELECT id, content
FROM docs
ORDER BY embedding <=> '[...]'::vector
LIMIT 10;
```
<=> 是余弦距离运算符，按距离从小到大排序，取前 10 条即为最相似的 10 条。
边界在哪里
pgvector 支持两种近似最近邻（ANN，Approximate Nearest Neighbor）索引：HNSW 和 IVFFlat，用它们可以把暴力扫描变成近似查询。但"近似"两个字是理解的钥匙——它用一点召回率换速度，索引类型、参数、数据分布都会影响结果，具体能力和参数含义以官方页面为准。
它真正的舒适区是这几种情况：
| 场景 | pgvector 是否合适 |
|---|---|
| 已有 Postgres，向量只是其中一个功能 | 很合适，零新增运维 |
| 需要"先按租户/时间/权限过滤，再排相似度" | 很合适，一条 SQL 就能表达 |
| 数据量中小规模、延迟要求不苛刻 | 通常够用 |
| 上亿向量、要求高并发低延迟 | 专用向量数据库更合适 |
| 写入极频繁、还要实时检索 | 索引维护会拖慢写入，需谨慎 |
最大的两个约束是内存和规模。HNSW 索引基本要常驻内存，维度越高、行数越多，吃得越狠；横向扩展、量化压缩这类能力也不是它的主场。
和相邻概念的区别
和 Milvus、Qdrant、Pinecone 这类专用向量数据库相比，pgvector 的卖点是"不引入新系统"：备份、监控、权限、事务全部沿用现有体系，代价是极限规模下的性能与功能深度。它和 Postgres 自带的全文检索（tsvector）也不冲突——后者匹配关键词，前者匹配语义，两者常组合成混合检索（hybrid search）。
对从业者的意义
选型时先问三个问题：向量有多少条？延迟要求多少？过滤条件复杂吗？如果答案温和，pgvector 能帮你省掉一整套技术栈。对普通人来说，你在电商里搜"适合送妈妈的真丝围巾"能搜到，背后很可能就是向量检索——pgvector 让中小团队不用自建昂贵基础设施也能上线这类功能。