vectorchord

值此马年新春开启之际，我们非常高兴地宣布发布 VectorChord 1.1。 VectorChord 1.0 是 Postgres 原生向量搜索的一个重要里程碑：它让大规模索引构建变得足够快，感觉就像日常迭代而非停机维护。在 1.1 版本中，我们在此基础上更进一步，推出了 RaBitQ8：这是一种全新的向量类型，相比 float32 可节省 4 倍存储空间并提供更快的搜索速度，同时召回率损失不到 1%。配合 RaBitQ4 以及更具可组合性的查询控制能力，VectorChord 1.1 已准备 …

两年前，当我们发布第一篇 pgvecto.rs 博客文章时，我们下了一个赌注：Postgres 是进行向量搜索的最佳场所。从那时起，我们一直围绕这个信念持续迭代——从支持过滤向量搜索的 VBASE，到更长维度的向量支持，再到 RaBitQ 量化方案以及对磁盘友好的索引布局。 随着 VectorChord 1.0 的到来，我们再次实现了突破。在一台 16 vCPU 的机器上，我们现在可以在 20 分钟内为 1 亿（100M）个向量构建好索引；而在相同规模下，pgvector 需要超过 50 个小时 …

我们非常激动地宣布发布 VectorChord 0.5！此次发布标志着我们在提供更灵活、更强大、更可控的向量搜索能力这一使命上迈出了重要一步。在 0.5 版本中，我们引入了两项重大更新：对 DiskANN 图索引的实验性支持，以及全新的用于主动监控 IVF+RaBitQ 索引健康状况的召回率评估工具。 全新索引预览：RaBitQ 赋能的 DiskANN 索引 从第一天起，VectorChord 的核心索引方案就建立在一个强大的组合之上：基于聚类的 IVF 算法与 RaBitQ 量化——也就是我们 …

现代应用普遍依赖 PostgreSQL 完全符合 ACID 的事务特性、表达力丰富的 SQL 以及繁荣的扩展生态系统。虽然 PostgreSQL 在处理关系型负载方面表现得无与伦比，但许多项目同样需要在庞大的文本集合（如商品描述、客服工单、技术文档）中进行搜索，并将最相关的行优先呈现给用户。PostgreSQL 的原生工具为此提供了一定基础，但其默认的排序逻辑往往会让最理想的匹配结果被淹没在不太有用的结果之下。VectorChord‑BM25 通过将 BM25 相关性评分算法直接引入 …

我们很高兴地宣布发布 VectorChord 0.4，这是一次全面增强 PostgreSQL 高性能向量搜索能力的重要更新。我们相信，此次发布进一步拓展了 PostgreSQL 向量搜索的能力边界，引入了多项关键架构改进，旨在为严苛的真实业务负载降低延迟并提升吞吐量。 如果你正在 PostgreSQL 上构建相似度搜索、RAG 流水线或其他 AI 驱动的应用，这些更新正是为你量身打造的。我们重点聚焦于两大领域：利用 PostgreSQL 不断演进的底层能力大幅提升冷查询（Cold Query）的 …

在本文中，我们将介绍一种利用真实世界的 LAION-400M 数据集和 PostgreSQL 中的 VectorChord 扩展，以高性价比方式上传、构建索引并搜索大规模向量数据的方法。 我们将向您展示需要什么样的硬件配置，才能使用 VectorChord 在这一海量数据集上进行搜索，并确保您获得既准确又快速的搜索体验。 VectorChord 是一款 PostgreSQL 扩展，能够将高性能向量数据库能力直接引入您的 PostgreSQL 数据库中，并尽可能高度兼容热门的 pgvector 扩 …

检索增强生成（Retrieval-Augmented Generation, RAG）正在彻底改变我们与海量数据集及语言模型的交互方式。通过在生成回答之前先检索相关信息，RAG 系统能够提供更准确、更具上下文感知能力且实时更新的答案。然而，构建稳健、可扩展且高效的 RAG 流水线依然面临诸多挑战，在生产环境中更是如此。 许多解决方案采用了复杂的架构，分别为向量搜索、关键词搜索和主数据存储使用不同的数据库。这通常会导致数据同步难题、更高的基础设施复杂度以及高昂的运维成本。 如果可以直接在你信赖的 …

为文档构建高效的检索增强生成（RAG）系统，往往让人感觉像是在与杂乱复杂的流水线搏斗。尤其是在处理 PDF 或扫描图像时，传统方法高度依赖光学字符识别（OCR）和版面分析。这些步骤不仅耗时、容易出错，而且经常会丢失表格、图表和排版格式等至关重要的视觉上下文信息。但如果可以直接根据文档的“视觉外观”进行查询，而不仅仅依赖提取出来的纯文本呢？ 本文将手把手带你构建这样一个系统：直接在你熟悉的 PostgreSQL 数据库中构建一套免 OCR 的 RAG 系统。我们将结合 ColQwen2 视觉语言模 …

我们非常激动地宣布发布 VectorChord 0.3！这一重要里程碑直接在你的 Postgres 数据库内部显著提升了高级向量搜索技术的性能与适用性。在带来 ARM 支持与更快索引构建的 0.2 版本基础上，0.3 版本攻克了现代检索领域的最大难关之一：具备晚期交互（Late Interaction）能力的高效多向量搜索。 超越单向量：为什么多向量如此强大 多年来，向量搜索主要将整篇文档或整个查询表示为单个稠密向量（Dense Vector）。这种方法虽然强大，但需要将复杂的信息平均或压缩为单 …

引言：真实场景中的挑战 并非所有场景都需要专用的向量数据库。借助 pgvector、pgvectorscale、VectorChord（演进自 pgvecto.rs）等 PostgreSQL 扩展，您可以在无需额外基础设施的情况下同时获得向量搜索与关系型数据库的能力。但实际落地并非总是顺风顺水，以下是真实用户的反馈： 首次查询耗时 30 秒，而重复查询只需 100 毫秒。问题出在极其缓慢的 I/O 上。 为 1,200 万行 75 维向量构建索引需要 3 个小时，这正常吗？ 在为 2 亿条 75 …

我们很高兴地宣布发布 VectorChord-BM25 0.2 版本！这款 PostgreSQL 扩展旨在将先进的基于 BM25 的全文检索排序能力直接引入您的数据库中。 借助 VectorChord-BM25，您无需依赖外部搜索引擎，即可直接利用信息检索领域的标准算法——BM25 的强大能力。本次发布迈出了重要一步，重点强化了核心文本处理组件：分词（tokenization），从而带来了更高的灵活性以及显著提升的多语言支持能力。 重磅消息：推出 pg_tokenizer.rs …

在 RAG（检索增强生成）时代，如何从海量数据集中高效检索相关数据，对企业和开发者而言至关重要。传统的基于关键词的检索方法（例如使用 BM25 作为评分机制的方法）擅长根据词频和精确关键词匹配对文档进行排序，因此对于结构化查询和关键词密集型内容非常有效。然而，它们在理解同义词、上下文细微差别和语义意图方面往往力不从心。相反，基于向量的检索能够捕捉深层语义，在多样化查询上具备更好的泛化能力，但有时会在精确关键词匹配上牺牲准确性。混合搜索（Hybrid Search）通过将 BM25 的精确性与向量 …

VectorChord 是一款专为可扩展、高性能且磁盘友好的向量相似度搜索而设计的 PostgreSQL 扩展，也是 pgvecto.rs 的继任者。在我们之前的博客文章中，我们展示了仅需每月 $250 的成本，VectorChord 就能在 1 亿规模的向量数据集上以 0.95 的精度实现 131 QPS——展现了大规模向量搜索中令人印象深刻的高性价比。 在此基础上，本文将聚焦于极致性能，探讨如何借助 VectorChord 在 PostgreSQL 中实现 10,000 QPS。我们将为您详 …

我们非常高兴与大家分享一款重磅新作：VectorChord-BM25，这是一款旨在让 PostgreSQL 全文检索更上一层楼的全新扩展。无论您是在构建小型应用还是管理大规模系统，这款工具都能将先进的 BM25 评分与排序能力直接引入 PostgreSQL，让您的搜索更智能、更迅速。 有哪些新特性？ BM25 评分与排序：借助 BM25 获得更精准、更相关的搜索结果，助您快速定位最重要的信息。 优化的索引结构：得益于 Block WeakAnd 算法，即便面对大规模数据集，搜索也能更加快速高效。 …

今天，我们非常激动地向大家分享 VectorChord 0.2——这是一个凝聚了社区反馈、旨在应对 PostgreSQL 向量搜索不断演进的挑战而打造的新版本。 %[https://github.com/tensorchord/VectorChord/] 优化存储布局：支持高达 60,000 维向量 在 PostgreSQL 中，基础存储单元是 8KB 的数据页（Page）。虽然这种设计对于大多数常规负载非常稳健，但它也给高维向量搜索等现代应用场景带来了限制。例如，受限于固定的页面大小 …

ARM64 正悄然成为高性价比云服务器的首选架构，尤其是在 AWS 上。借助 Graviton 系列（Graviton3 和 Graviton4）等基于 ARM 的处理器，你可以在不牺牲性能的前提下节省一大笔开销。这些 ARM64 实例比传统的 x86 实例实惠得多，是在云端平衡成本与性能的可靠选择。 话虽如此，由于 ARM 的架构与 x86 不同，未针对其进行优化的软件可能会因为指令模拟或缺乏优化而运行缓慢。这正是 VectorChord 大显身手的地方——它是一款专为可扩展、高性能且磁盘高效 …

聚类（Clustering）是向量搜索中的重要组成部分，而 K-means 算法依然是目前应用最广泛的技术之一。然而，它的简洁性也伴随着一个显著的缺点：密集的计算资源消耗使其在处理大规模数据集时往往力不从心。本文将探讨这一挑战产生的原因，并介绍如何利用外部构建（External Builds）来克服它，同时分享我们在实现这一方案过程中的技术洞察。 为什么需要外部构建 VectorChord 使用 IVF + RaBitQ 来执行向量搜索。IVF 聚类簇的质量会直接影响搜索精度和速度 …

我们很高兴地宣布推出全新的 PostgreSQL 向量搜索扩展，为大规模向量管理提供极具性价比的解决方案。使用 VectorChord，您可以在 1 亿条 768 维向量数据集上执行 Top 10 查询时，以 0.95 的精度实现 131 QPS。整套环境可在单台机器上运行，每月成本仅为 $250。 这意味着您只需花费 $1 即可存储 40 万条向量，从而大幅节省成本：在同等价格下，可存储的向量数量是 Pinecone（存储优化型实例）的 6 倍，更是 pgvector/pgvecto.rs 的 …