# 与 pgvectorscale 的基准测试对比
> 对比 VectorChord 与 pgvectorscale 在内存与磁盘场景下的 QPS、Recall@10/100、索引构建时间及插入性能。
---
LLMS 索引： [llms.txt](/zh/llms.txt)
---
在本节中，我们将 VectorChord 与提供向量相似性检索能力的 PostgreSQL 扩展 pgvectorscale 进行对比。我们将重点关注四个核心指标：QPS（每秒查询数）、Recall@10/100、索引构建时间（Index Building Time）以及数据插入时间（Insertion Time），并同时探讨内存与磁盘场景下的性能表现。如果您对我们的实现细节感兴趣，请参阅我们的博文《[PostgreSQL 上的向量检索：内存与磁盘方案的对比分析](/zh/blog/post/vector-search-over-postgresql-a-comparative-analysis-of-memory-and-disk-solutions/)》。
## QPS 与召回率 {#qps--recall}
### 内存表现 {#memory}
上图展示了查询速度（QPS）与检索质量（Recall@10/100）之间的权衡关系。Recall@10 衡量在前 10 个返回结果中找到真实最近邻向量的比例。通常情况下，牺牲一定的召回率可以换取更高的 QPS，反之亦然。更优秀的系统能够在相同 QPS 下实现更高的召回率，或在相同召回率水平下提供更高的 QPS。我们的目标通常是在保持高召回率目标（例如 95%）的前提下最大化 QPS。
### 磁盘表现 {#disk}
一如既往，在高召回率区间（例如 Recall@10 > 95%），VectorChord 始终能够取得高于其他扩展的 QPS，而 pgvector 与 pgvectorscale 的 QPS 表现则较为接近，位列其后。
## 索引构建 {#index-building}
与 pgvectorscale 相比，VectorChord 能够更充分地利用 CPU 资源、减少内存占用，并大幅缩短索引构建时间。
## 数据插入时间 {#insertion-time}
如图所示，在数据插入性能方面，VectorChord **（1565 次插入/秒）** 的表现远超 pgvector **（246 次插入/秒）** 和 pgvectorscale **（107 次插入/秒）**。对于大多数工作负载而言，100 次插入/秒已经足够；但如果您在生产环境中需要持续高频地写入大量向量（例如达到 500 次插入/秒），其他扩展的写入瓶颈就会成为一个棘手的问题。