Windows安装pgvector：Docker与原生编译全指南

1. 为什么是pgvector，以及Windows下的现实困境

这两年做AI应用，尤其是检索增强生成（RAG）类的项目，几乎绕不开一个需求：把文档切块、转成向量、存起来，然后在问答时做相似度检索。市面上的向量数据库不少，Milvus、Chroma、Weaviate各有各的亮点，但如果你已经有PostgreSQL在跑业务数据，再为向量单独引入一套服务，总觉得有点重。我第一次接触pgvector时，最直观的感受就是：它把向量当成一种普通的数据类型塞进了PostgreSQL里，建表、插入、查询都遵循SQL习惯，学习成本低到几乎可以忽略。

pgvector是PostgreSQL的一个扩展，核心能力是提供vector数据类型，以及欧氏距离（L2）、内积（IP）、余弦距离（Cosine）三种向量相似度算子，同时支持HNSW和IVFFlat两种索引。它解决的核心问题是：在你的应用里，怎样低成本地实现"给出一段文本的向量，找出库里最相似的N条文本"。对于中小体量的语义搜索、推荐去重、RAG知识库这些场景，pgvector完全够用，而且省去了数据双写、同步延迟的烦恼。

不过，想在Windows下把pgvector装起来，多少要费点周折。pgvector官方发布的是源码包，主力支持Linux和macOS，Windows上既没有官方安装向导，也没有现成的MSI安装包。很多人在网上搜到的教程都是Linux命令，make && make install一步到位，到了Windows上却不适用。我自己第一次装的时候，卡在编译环节折腾了一整天，最后被Docker方案救了回来。这篇文章就把两条可走的路都讲清楚：一条是省心的Docker容器化方案，另一条是Windows原生编译方案，以及我踩过的所有坑和排查思路。无论你是只想在本地快速跑通一个demo，还是因为团队基础设施限制必须用原生Windows版，都能找到对应的解法。

2. 安装前必须想清楚的三件事

2.1 PostgreSQL版本：别在旧版本上浪费时间

pgvector不是所有PostgreSQL版本都能装。早期版本的pgvector支持PostgreSQL 11以上，但越往后要求越高，比如新版pgvector 0.7.x要求PostgreSQL 12以上，再新一些的版本对16、17的支持更好。我的建议很直接：如果你现在还没装PostgreSQL，直接装16或17，这是当下主流且生态最成熟的版本。如果已经装了旧版本（比如12、13），能用是能用，但后续如果要升级pgvector或者折腾新特性，容易碰壁。

这里有一个容易忽略的点：Docker方式安装时，镜像标签就对应PostgreSQL版本。官方pgvector镜像的pgvector/pgvector:pg16就是PostgreSQL 16 + pgvector的组合，pg17就是PostgreSQL 17的方案。版本选择要和你实际业务环境对齐，别在本地用16，生产环境用12，最后发现SQL行为对不上。本地开发环境尽量和生产保持一致，这是所有数据库类工具的第一条铁律。

2.2 安装方式选型：Docker还是原生编译

我先说结论：个人开发、测试、学习，首选Docker。团队强制要求原生安装，或者你所在的网络环境明确不允许容器化，才考虑原生编译路线。

这不是说Docker就完美，容器在Windows上依赖WSL2后端，如果你机器上的WSL2没更新，Docker Desktop会直接罢工。但这些问题都有成熟的排查路径，比编译源码遇到的坑好解决得多。我个人的建议是：先用Docker跑通整个流程，理解pgvector的用法和索引机制，如果将来确实需要原生环境，再考虑编译不迟。不要一上来就挑战高难度，没必要。

2.3 确认你的向量数据量级

安装pgvector本身不难，难点在后期怎么用得顺手。做语义搜索时，向量维度通常很高：OpenAI的text-embedding-3-small是1536维，text-embedding-3-large是3072维，本地模型比如BGE-M3也有1024维。一条文本向量占用的空间在几十KB到几百KB之间。如果你的数据量是几千条，全表扫描也能在毫秒级返回，索引都不是必须的。但如果到了几十万条以上，没有索引的查询会慢到让你怀疑人生。

所以在安装之前，想清楚你的场景：是存几百条测试数据，还是要支撑一个真正的知识库？这决定了你后面用不用索引、用哪种索引、参数怎么调。这一步想清楚了，后面就不会为了性能问题反复折腾。

3. 方案一：Docker容器化安装，五步搞定

3.1 拉取pgvector官方镜像

打开Windows上的Docker Desktop，确认Docker引擎已经启动，然后打开PowerShell或CMD，执行：

bash复制docker pull pgvector/pgvector:pg16

这个镜像是pgvector社区官方维护的，里面已经装好了PostgreSQL 16和pgvector扩展，不需要你再去手动编译，拉下来就能用。如果你需要其他PostgreSQL版本，把标签换成pg12、pg13、pg14、pg15、pg17即可。

拉取过程中如果遇到网络问题，可以考虑配置Docker的镜像加速器。Windows下Docker Desktop的设置里可以直接配置 registry mirror，具体地址根据你的网络环境选定。这一步是多数人第一次卡住的地方，问题不大但很烦。

3.2 创建并启动容器

镜像拉取完成后，执行：

bash复制docker run -d --name pgvector-demo -e POSTGRES_USER=postgres -e POSTGRES_PASSWORD=postgres -e POSTGRES_DB=vector_db -p 5432:5432 pgvector/pgvector:pg16

逐项解释一下：

• -d：后台运行容器。
• --name pgvector-demo：给容器起一个名字，方便后续管理。
• -e POSTGRES_USER=postgres：设置数据库超级用户。
• -e POSTGRES_PASSWORD=postgres：设置密码。本地开发可以用简单的，生产环境务必换成强密码。
• -e POSTGRES_DB=vector_db：启动时自动创建的数据库名称。
• -p 5432:5432：把容器内的5432端口映射到宿主机的5432端口。

执行完后，用docker ps查看容器状态，如果STATUS是Up，说明启动成功。如果状态是Exited，别急，看下文踩坑章节，大概率是端口冲突或WSL2问题。

3.3 验证扩展是否可用

进入容器，用psql连接数据库：

bash复制docker exec -it pgvector-demo psql -U postgres -d vector_db

在psql里执行：

sql复制CREATE EXTENSION vector;

看到CREATE EXTENSION的提示就说明成功了。再执行：

sql复制SELECT * FROM pg_available_extensions WHERE name = 'vector';

可以看到pgvector的版本信息。这一步验证完毕，扩展就已经可以使用了。后面建表、插入向量、做相似度查询，都是标准的SQL操作。

3.4 让容器数据持久化

容器默认是"一次性"的，如果哪天你把容器删了，里面的数据全没。我第二次跑demo的时候就不小心docker rm把数据清了，当时想死的心都有。正确的做法是挂载volume：

bash复制docker run -d --name pgvector-demo -e POSTGRES_PASSWORD=postgres -v pgvector_data:/var/lib/postgresql/data -p 5432:5432 pgvector/pgvector:pg16

其中-v pgvector_data:/var/lib/postgresql/data是创建一个名为pgvector_data的Docker卷，挂载到容器内的PostgreSQL数据目录。这样即使容器被删，数据也还在卷里，重新用同一镜像启动并挂载同一个卷，数据就回来了。

3.5 容器的性能提醒

容器化对性能的影响在开发环境几乎感觉不出来，但有几个小点值得注意：

• 如果是机械硬盘，建议把Docker的数据目录放到SSD上，否则向量查询的磁盘IO会拖后腿。
• 挂载卷时，尽量不要把Windows的NTFS目录直接挂给PostgreSQL数据目录（比如-v D:\pgdata:/var/lib/postgresql/data），Windows文件系统和Linux容器之间的IO开销可能成为瓶颈。用Docker卷（默认存储在WSL2的虚拟磁盘里）通常会更快。
• 如果计划长期使用，给Docker Desktop分配足够的内存，建议至少4GB以上给虚拟机，否则PostgreSQL内存不足时性能下降很明显。

4. 方案二：Windows本地编译安装pgvector

4.1 准备工作：你需要哪些东西

Docker方案虽然省心，但有些公司内部不允许用Docker，或者生产环境就是Windows裸机部署PostgreSQL，那就必须走原生编译路线。这里我如实说一句：pgvector官方项目没有为Windows提供官方的MSI安装包，也没有维护一套完整的Windows编译脚本。网上能找到的Windows二进制，一类是第三方开发者自行编译后发布在GitHub上的（需要谨慎评估来源和安全性），另一类就是自己啃源码编译。

如果你想自己编译，需要准备以下环境：

• PostgreSQL 16的Windows版（EnterpriseDB安装包）。安装时建议勾选"Stack Builder"和开发组件，确保PostgreSQL安装目录下有bin文件夹，里面包含pg_config.exe，这是编译扩展的关键工具。
• Visual Studio Build Tools，勾选"使用C++的桌面开发"工作负载。
• pgvector源码，从GitHub的Release页面下载对应版本的源码压缩包。

4.2 编译过程：真正的挑战在这里

先说明一点：pgvector源码里没有Windows专用的Makefile.w32，官方也不保证Windows下make能顺利通过。这跟其他一些PostgreSQL扩展不太一样。因此，在Windows上编译pgvector需要借助PostgreSQL的扩展构建机制，通常有两种路子：

第一种，用MSYS2/MinGW环境。在MSYS2里安装mingw-w64-x86_64-gcc、make等工具，然后设置PGPATH指向PostgreSQL安装目录，执行make && make install。这个方案的难点在于环境配置复杂，各种依赖路径容易出错。

第二种，使用Visual Studio的nmake方式，但前提是pgvector源码里提供了对应的构建文件。就目前来看，这个路子对pgvector并不顺畅，很多人在这一步骤失败。所以如果你非要原生编译，我建议先查一下PostgreSQL的官方文档中"Extension Building"部分的Windows说明，以及pgvector的GitHub Issues里有没有人分享过成功经验。

我的个人建议是：除非你有充分的理由和充裕的排错时间，否则不要轻易尝试Windows原生编译。我自己在Windows上编译其他PostgreSQL扩展（比如postgis）时吃过不少苦头，pgvector的坑只会更多。如果确实需要原生环境，优先尝试网上口碑较好、star数较高的预编译release包，但安装前务必备份数据、评估风险。

4.3 如果拿到了可用的扩展文件

假设你成功编译出了vector.control、vector.dll、vector--*.sql这些文件，或者从可信来源下载到了这些文件，安装步骤其实不复杂：

1. 把vector.dll和vector.control放到PostgreSQL安装目录下的lib和share/extension目录。
2. 把vector--*.sql文件放到share/extension目录。
3. 在PostgreSQL的conf里确认没有禁用动态库加载。
4. 用psql连接数据库，执行CREATE EXTENSION vector;。

如果执行CREATE EXTENSION时报错找不到libvector.dll或者提示版本不匹配，多半是文件没有放对位置，或者PostgreSQL位数和DLL位数不一致。PostgreSQL是64位的，你的DLL也必须是64位编译的，32位编译出来的是直接无法加载的。

4.4 对原生编译路线的最终评价

写这么多，我对Windows原生编译pgvector的总体评价是：可以搞，但性价比低。官方不提供支持、社区资料零散、环境差异大，每一步都可能踩坑。如果只是想在Windows上开发调试，Docker版本提供的功能完全一致，逻辑层零区别，何必为难自己。如果生产环境是Windows Server，更推荐的做法是评估一下是否需要转向Linux环境，PostgreSQL在Windows上的生产部署本身就相对少见，再加上pgvector的维护负担，长期看并不是一个舒服的组合。

5. 基础使用演示：从建表到相似度查询

5.1 创建扩展与建表

无论你是用Docker还是原生安装，后续的SQL操作是完全一样的。这也是pgvector最吸引人的地方——它把向量检索变成了一门SQL语言，你不需要学会新的查询API。

先创建扩展：

sql复制CREATE EXTENSION IF NOT EXISTS vector;

然后建一张带向量字段的表：

sql复制CREATE TABLE documents (
  id bigserial PRIMARY KEY,
  title text NOT NULL,
  content text NOT NULL,
  embedding vector(1536)
);

这里vector(1536)表示该列存储的向量维度是1536。实际维度必须和你用的Embedding模型输出维度完全一致，这是pgvector的一个硬性约束——如果插入的向量维度不一致，直接会报错。比如你用text-embedding-3-small生成的就是1536维，用BGE-M3生成的是1024维，这两个模型的数据不能混存在同一个向量列里，除非你统一做降维或对齐。

5.2 插入向量数据

插入语句看起来和普通表没什么两样：

sql复制INSERT INTO documents (title, content, embedding)
VALUES (
  'pgvector安装教程',
  '在Windows下安装pgvector扩展，并使用向量存储实现语义检索。',
  '[0.012, -0.034, 0.025, ...]'
);

向量的表示方式与JSON数组类似，就是方括号包裹的浮点数列。实际项目中，这部分数据不是人肉写的，而是通过程序调用Embedding接口生成后拼进SQL。下面是一个Python伪代码示例，帮助理解：

python复制import psycopg2

def insert_document(title, content, embedding):
    conn = psycopg2.connect("host=localhost user=postgres password=postgres dbname=vector_db")
    cur = conn.cursor()
    embedding_str = "[" + ",".join(str(x) for x in embedding) + "]"
    cur.execute(
        "INSERT INTO documents (title, content, embedding) VALUES (%s, %s, %s)",
        (title, content, embedding_str)
    )
    conn.commit()
    cur.close()
    conn.close()

实际使用中，应该把数据库连接做成连接池，避免每次插入都重新建立连接。后面我会给一个更完整的示例。

5.3 三种距离函数：怎么选

pgvector提供了三种距离算子，对应三种不同的相似度度量方式：

大多数RAG项目选择余弦距离（<=>）或欧氏距离（<->）。如果生成向量的Embedding模型做了归一化（很多模型默认这么做），余弦距离和欧氏距离的结果排序是一致的，这时候用<->也没问题。我的习惯是：先用余弦距离跑通，后续再根据需要切换。

5.4 一个完整的查询案例

假设我们要从documents表中找到与某条query最相似的5条文本：

sql复制SELECT id, title, content, 1 - (embedding <=> '[0.012, -0.034, 0.025, ...]') AS similarity
FROM documents
ORDER BY embedding <=> '[0.012, -0.034, 0.025, ...]'
LIMIT 5;

这条SQL的意图很清晰：计算表中每一行的embedding与目标向量的余弦距离，按距离排序，取前5条。1 - 距离就是余弦相似度，值越接近1越相似。如果表中的数据量比较大，这个查询在没有索引的情况下会做一个全表扫描，速度会随着数据量上升直线恶化。这就引出下一节的内容。

6. 索引与性能优化

6.1 为什么需要向量索引

没有索引时，PostgreSQL执行相似度查询需要把表里所有向量依次读出来做距离计算，时间复杂度和数据量成正比。几千条数据问题不大，但到了几十万条，一次查询可能要几百毫秒甚至秒级，这在语义搜索场景下是难以接受的。pgvector提供了两种索引来加速：IVFFlat和HNSW。它们的原理都不复杂，但选错、配错参数会让索引效果大打折扣。

6.2 HNSW索引：优先推荐

HNSW是一种基于图的近似最近邻算法，构建索引时把向量组织成多层图结构，查询时从顶层快速下探到合适的邻居区域。pgvector对HNSW的实现在查询准确率和性能的平衡上做得很好，是我在绝大多数项目中的首选。

创建HNSW索引的语法：

sql复制CREATE INDEX ON documents USING hnsw (embedding vector_cosine_ops);

这里的vector_cosine_ops指定了索引适用的距离函数类型。三种距离函数对应三种运算符类：

sql复制CREATE INDEX ON documents USING hnsw (embedding vector_l2_ops);      -- 欧氏距离
CREATE INDEX ON documents USING hnsw (embedding vector_ip_ops);      -- 内积
CREATE INDEX ON documents USING hnsw (embedding vector_cosine_ops);  -- 余弦距离

可以指定额外的参数来控制索引质量：

sql复制CREATE INDEX ON documents USING hnsw (embedding vector_cosine_ops) WITH (m = 16, ef_construction = 64);

• m：每个节点最多连接的数量，默认16。值越大，图越密，查询精度越高，但内存和构建时间也越大。
• ef_construction：构建索引时考虑的候选数量，默认64。值越大索引质量越好，但构建越慢。

HNSW索引的查询参数ef_search也在查询时动态控制检索精度：

sql复制SET hnsw.ef_search = 100;

数值越大，查询越准确，但响应越慢。我一般设置一个适中的值，比如100，精确度和性能的平衡比较舒服。

6.3 IVFFlat索引：老牌选手，但需要先训练

IVFFlat把向量空间划分为多个列表（list），查询时先定位到最相关的几个列表中做精确搜索，思路有点像"先粗筛再细找"。它的坑在于：表里得有数据，且数据量足够大，构建索引时才能通过KMeans算法训练出好的列表划分。如果你在建索引时表里只有几百条数据，之后数据涨到几十万条，索引的划分早就失真了，需要重新建索引。

创建IVFFlat索引的语法：

sql复制CREATE INDEX ON documents USING ivfflat (embedding vector_cosine_ops) WITH (lists = 100);

lists参数是列表数量。一个经验法则是：lists取sqrt(数据量)附近的值。比如100万条数据，lists大概取1000。

6.4 索引选型建议

从实践经验看，HNSW是"默认答案"，绝大多数场景不需要犹豫。IVFFlat更像是特定资源约束下的选择。我在一个30万条数据的知识库上做测试，HNSW的查询延迟稳定在10毫秒左右，IVFFlat在列表参数调优后也能到20毫秒上下，但参数调优过程中走了不少弯路。如果不是碰到底层性能瓶颈，HNSW足够让人睡得安稳。

7. 高频踩坑实录：我遇到的5个问题

7.1 问题一：Docker容器启动后立刻退出

第一次拉镜像跑容器，docker ps发现容器已经退出，用docker logs pgvector-demo查看日志，里面写着port 5432 is already in use或者类似的信息。这是Windows上最典型的问题——本机的5432端口已经被占用了，通常是之前安装过PostgreSQL，或者另一个Docker容器先行占用了端口。

排查思路：在PowerShell里执行netstat -ano | findstr 5432，看到PID后到任务管理器找到对应进程。如果确实是本地PostgreSQL在跑，有两个选择：停掉本地服务，或者把新容器的端口映射改掉。我选择了后者，把映射改成了-p 55432:5432，这样本地旧库和新容器可以并存，只是新的容器需要通过localhost:55432访问。做开发调试时，改端口比停服务更安全，不影响其他正在用的工具。

7.2 问题二：WSL2未更新导致Docker Desktop无法启动

Docker Desktop用久了，某天突然弹窗提示WSL2需要更新才能继续使用。这通常发生在Windows 10较老版本上。解决方法是执行wsl --update，或者到Microsoft官方下载最新的WSL2内核更新包。更新完成后，重启Docker Desktop通常就好了。这个坑虽然和pgvector本身无关，但在Windows下用Docker装任何服务都会遇到，先排查这个可以省去很多焦虑。补充一句，尽量用Windows 11或更新的Windows 10版本做开发，WSL2的稳定性明显更好。

7.3 问题三：CREATE EXTENSION时提示找不到扩展

在psql里执行CREATE EXTENSION vector;，结果报错extension "vector" is not available。可能的原因有两种：

第一种，镜像选择错了。没有用pgvector/pgvector镜像，而是用普通postgres镜像，普通镜像默认不包含pgvector扩展。你需要CREATE EXTENSION之前手动到镜像里去下载安装，但普通postgres镜像里没有编译工具链，折腾起来很麻烦。所以第一选择还是直接用pgvector官方镜像。

第二种，原生安装时vector--*.sql文件没放对位置。检查PostgreSQL安装目录下的share/extension文件夹，确认文件命名是否符合PostgreSQL的规范。另外还需要确认PostgreSQL读取的extension目录是不是你放文件的目录，用SHOW data_directory;和SHOW config_file;来核对实例配置，再结合pg_config --sharedir确认路径。

7.4 问题四：维度不匹配导致插入失败

插入向量时，报错expected 1536 dimensions, not 1024。这就是我前面提到的维度校验。出现这个错误，说明某条数据的向量维度和建表时定义的vector(1536)不一致。常见原因：部分文本调用的是不同的Embedding模型，或者Embedding接口在请求失败时返回了不同长度的兜底向量。处理办法：建表前统一确认模型维度，插入前做一次长度校验，发现异常直接拦截并记录日志。这个小改动在项目上线后能救你很多次。

7.5 问题五：查询慢，加了索引还是慢

有一次我在测试阶段发现，建了HNSW索引，但查询还是接近全表扫描的速度。排查后发现，索引在左列上生效了，但查询SQL写错了类型。pgvector要求查询时参数类型必须是vector类型，如果你程序传参是字符串，PostgreSQL可能会做隐式转换或者放弃索引走全表扫描。解决办法：参数类型显式转换为vector，比如WHERE embedding <=> $1::vector。另外，在SQL前面加EXPLAIN ANALYZE看执行计划，如果看到Seq Scan，说明索引没被用到，逐一排查。

8. 落地案例：给本地RAG应用做向量库

8.1 场景与架构

最近我在Windows上搭了一个本地的RAG问答系统，技术栈是这个组合：文档解析（PDF/Markdown）→ 切片 → 调用Embedding模型生成向量 → 存入pgvector → 问答时把问题向量化，到pgvector里做TopK检索 → 把检索结果拼进系统提示词，交给大模型生成答案。整个链路中，pgvector扮演的是知识库存储和召回的角色。

这个架构最大的好处是：不需要单独部署向量数据库。业务数据在PostgreSQL里，向量也在PostgreSQL里，事务、备份、权限体系都是一套。对于个人项目和小团队来说，省掉了运维复杂度和数据同步环节。

8.2 用Python写入向量

下面是写入部分的核心代码，基于psycopg2，适配Windows + PostgreSQL环境：

python复制import psycopg2
import numpy as np

DB_CONFIG = {
    "host": "localhost",
    "port": 5432,
    "user": "postgres",
    "password": "postgres",
    "dbname": "vector_db"
}

def insert_document(title: str, content: str, embedding: np.ndarray):
    embedding_list = embedding.tolist()
    embedding_str = "[" + ",".join(map(str, embedding_list)) + "]"
    sql = """
        INSERT INTO documents (title, content, embedding)
        VALUES (%s, %s, %s::vector)
    """
    with psycopg2.connect(**DB_CONFIG) as conn:
        with conn.cursor() as cur:
            cur.execute(sql, (title, content, embedding_str))

注意embedding_str的类型是字符串，但我们在SQL里用::vector把它转成vector类型，这一步可以避免很多隐式转换的问题。在批量导入时，建议使用executemany或COPY命令来提升效率，单条INSERT循环在数据量大时性能很差。

8.3 检索验证

检索端的关键代码：

python复制def search_similar(query_embedding: np.ndarray, top_k: int = 5):
    embedding_list = query_embedding.tolist()
    embedding_str = "[" + ",".join(map(str, embedding_list)) + "]"
    sql = """
        SELECT id, title, content, 1 - (embedding <=> %s::vector) AS similarity
        FROM documents
        ORDER BY embedding <=> %s::vector
        LIMIT %s
    """
    with psycopg2.connect(**DB_CONFIG) as conn:
        with conn.cursor() as cur:
            cur.execute(sql, (embedding_str, embedding_str, top_k))
            rows = cur.fetchall()
    return rows

验证时，我拿了一条与库中某条文档语义相同但表述不同的查询，结果Top1准确命中了那条文档。如果你的相似度结果看起来不对，先检查Embedding模型的输入是否经过了相同的预处理（比如长度截断、cleanup策略），很多时候问题不是pgvector，而是上游Embedding文本处理不一致。

8.4 与dify、codex这类工具配合时的思路

如果你在用dify或者其他低代码RAG平台，底层的向量库很多也支持PostgreSQL+pgvector。这意味着，你在Windows本地用pgvector做的开发、验证的数据结构，迁移到dify里可以直接复用或参照。甚至在一些AI编程助手（包括codex这类命令行工具）的本地配置中，也会涉及到把索引、检索库指向pgvector的方案。由于这些工具的默认配置和社区资料偏向Docker部署，Windows环境下的做法是：先把PostgreSQL+pgvector跑起来，然后在工具的配置项里指定数据库连接串，结构上完全兼容。

我的体会是，把pgvector作为RAG的底座，能让你在调试时直接用SQL查看库里的数据，不用额外学习向量数据库的管理命令。这种"少学一个系统"的价值，在日常开发中比想象中更宝贵。我曾对比过我把同样一套数据分别放进Chroma和pgvector，pgvector的调试体验明显更顺手，尤其是在团队里有人已经熟悉PostgreSQL的情况下。

最后分享一个我实际的项目经验：在Windows开发机上用Docker跑pgvector，配合本地Embedding模型（比如通过Ollama或API调用），做一个几千到几万条知识文档的轻量RAG应用，性能完全够用，开发体验也相当顺滑。如果你只是被安装步骤卡住，别怕，走一遍上面Docker方案流程，半小时内你就能开始写第一个向量检索查询了。而如果后续真的需要上生产，再把这套逻辑迁移到Linux服务器或云数据库服务，pgvector的学习成本不会打水漂。