数据库原生 AI：当你的 Postgres 学会了嵌入

大多数 RAG 架构长得都一样：你的应用从 Postgres 读取数据，将文本发送到嵌入 API，将向量写入 Pinecone 或 Weaviate，并在读取时查询两个系统。你维护着两个数据存储、两套一致性模型、两套备份策略，以及一条同步管道——这条管道总是离让你的向量索引落后源数据数周只差一个边缘情况。

如果数据库自己就能搞定一切呢？这已经不再是假设。PostgreSQL 扩展如 pgvector、pgai 和 pgvectorscale——以及 AlloyDB AI 等托管服务——正在将整个嵌入与检索堆栈折叠进数据库本身。结果不仅仅是减少了活动部件，而是一种根本不同的运维模型：你的向量始终与其所代表的数据保持事务一致。

你不知道自己正在构建的集成层

标准 RAG 管道带有一项隐形税。在你的关系数据库和向量存储之间，存在着一个集成层：一组 worker 监听数据变更、调用嵌入 API、处理速率限制和重试、将结果写入向量数据库，并以某种方式保证两个系统保持同步。

这个层往往悄悄增长。它最初是一个在 cron job 上运行的简单脚本。然后有人注意到删除的行留下了孤立的向量。然后一个 schema 变更破坏了文本提取逻辑。然后嵌入 API 的速率限制导致了一个花三天才能清理的积压。不知不觉中，你拥有了一条自定义 ETL 管道，有着自己的故障模式、监控和 on-call 轮值。

数据库原生方案完全消除了这个层。当嵌入在持有源数据的同一个数据库中生成和存储时，一致性就不再是一个分布式系统问题——而是一个事务。

数据库原生嵌入的实际工作原理

不同工具的实现细节有所不同，但核心模式是一致的：你声明要嵌入什么，数据库处理其余的一切。

pgai，Timescale 的扩展套件，使用声明式向量化模型。一条 SQL 语句告诉系统要嵌入哪个表和列、使用哪个模型、以及将结果存储在哪里。在幕后，pgai 使用逻辑复制来检测变更，而不会阻塞应用写入。无状态的 worker 容器拉取待处理的修改，批量调用嵌入模型，并通过 COPY 操作将结果写回。日志序列号（LSN）跟踪保证了精确一次语义——没有重复的嵌入，没有遗漏的行。

AlloyDB AI，Google 的托管 PostgreSQL 服务，采用了类似但更紧密集成的方法。自动向量嵌入于 2026 年 3 月正式发布，支持事务模式（数据变更时嵌入立即更新）和手动模式（高写入量工作负载的延迟更新）。批量嵌入管道通过使用基于数组的批处理操作实现了高达 130 倍的加速，让查询优化器动态调整批大小。

两种方法共享一个关键特性：你的应用代码不需要知道嵌入的存在。数据库将它们作为数据的派生产物来维护，就像维护索引一样。

性能：比你想象的更接近

传统观点认为专用向量数据库更快。这在 2023 年是对的。现在已经远没那么准确了。

pgvectorscale，Timescale 为 pgvector 添加 StreamingDiskANN 索引的扩展，在 5000 万向量上以 99% 的召回率实现了每秒 471 次查询。作为参照，Qdrant 在相同召回率和可比硬件上实现 41 QPS——PostgreSQL 领先 11 倍。在相同规模下，pgvectorscale 的 p95 延迟比 Pinecone 的 s1 层级低 28 倍。

AlloyDB AI 使用 Google 的 ScaNN 算法，与 Google 搜索使用的相同。与标准 PostgreSQL HNSW 索引相比，它提供了高达 10 倍更快的索引创建和 4 倍更快的向量搜索查询。对于过滤向量搜索——生产中你真正需要的那种，在租户、日期范围或类别内搜索——加速可达 10 倍。

专用数据库明确胜出的规模阈值已经提高。2024 年，该阈值大约在 1000 万向量。到 2026 年，pgvectorscale 和 AlloyDB AI 在大约 1 亿向量以内都具有竞争力。超过这个规模——真正的十亿级向量——Milvus 等专用系统在分片和分布式查询执行方面仍有架构优势。

对大多数生产工作负载来说，1 亿向量已经绰绰有余。如果你在构建产品搜索引擎、客服 RAG 系统或内部知识库，你不太可能碰到这个上限。

运维论证比性能论证更有力

即使专用向量数据库在每个规模上都更快，数据库原生 AI 的运维论证仍然令人信服。

**一套备份策略，而非两套。**你的向量在 Postgres 中。它们受你现有的备份、时间点恢复和复制基础设施覆盖。你不需要弄清楚如何将 Pinecone 恢复到与同一时间戳的 Postgres 备份一致的状态。

**一套一致性模型。**当一行被插入、更新或删除时，相应的嵌入在同一事务上下文中跟随（或在具有精确一次保证的定义良好的异步管道中）。不存在向量索引说文档存在而关系数据库说它一小时前就被删除的时间窗口。

**一套访问控制模型。**行级安全、角色和权限授予对向量数据的适用方式与对其他一切的适用方式相同。你不需要跨两个数据库维护并行的权限系统。

**一种查询语言。**将向量相似度与关系过滤、连接和聚合结合的混合查询就是 SQL。你不需要从向量数据库获取候选 ID，然后在应用层从 Postgres 填充它们——这种模式不可避免地导致 N+1 问题和一致性差距。

**一个监控界面。**pg_stat_statements、EXPLAIN ANALYZE 和你现有的 Postgres 监控堆栈也涵盖向量操作。你不需要为向量查询延迟设置单独的仪表板。

数据库原生 AI 不适用的场景

这并非普遍适用的正确架构。有些明确的场景中，专用向量数据库值得其运维开销。

**十亿级向量规模。**如果你确实需要在超过数亿向量中以亚 100ms 延迟进行搜索，专用分布式系统能处理 PostgreSQL 并非为之设计的分片、复制和查询路由。

**多模型向量工作负载。**如果你的主要工作负载是向量操作——不是带向量组件的关系查询，而是带最少关系上下文的向量优先搜索——针对该访问模式优化的数据库会更高效。

**GPU 加速推理。**除 PostgresML 外，大多数数据库原生解决方案调用外部嵌入 API。如果你需要在本地 GPU 上运行带有自定义微调权重的嵌入模型，专用推理与存储管道会给你更多控制权。

**组织分离。**如果你的 ML 团队和数据工程团队独立运营，有不同的部署节奏，强制两者通过同一个 Postgres 实例可能产生超过架构简洁性收益的协调开销。

诚实的决策框架：从 pgvector 开始。你可能已经在运行 Postgres。运维简洁性是真实的。只有在你有证据——而非猜测——表明你已经超越它时，才迁移到专用系统。

融合正在加速

趋势线很清晰。每个主要云提供商都在将 AI 能力直接构建到他们的托管数据库服务中。Azure Database for PostgreSQL 现在支持从 SQL 调用 LLM。AlloyDB AI 在不离开数据库的情况下生成嵌入。Timescale 的 pgai 套件将任何 Postgres 实例变成检索引擎。

这种融合不仅仅关乎便利性。它反映了一个更深层的洞察：对大多数应用来说，向量不是需要单独数据库的单独数据类型。它们是你现有数据的派生表示，应该紧挨着它们所代表的数据，受同样的事务、同样的访问控制和同样的运维实践管理。

独立向量数据库的时代并没有结束。但其可寻址市场正在缩小到规模谱系的真正极端端。对于构建 AI 驱动应用的大多数团队来说，正确的向量数据库就是你已经拥有的那个。