正在加载，请稍候
DynamoDB 原生向量搜索已开放，向量与业务数据同表存储。对企业 RAG 架构，独立向量库的同步链路、双写一致性与成本账都要重算。
8 月 23 日，InfoQ 报道 Amazon DynamoDB 开始原生支持 AI 搜索：向量与业务数据同表存储，直接用 SearchVectors API 查询。对把知识库双写到独立向量库的团队，这意味着整个同步层可以删掉了。
这篇不讨论分块和 Embedding，只聚焦存储层：当主库自己会做向量检索，企业 RAG 架构里"再养一个向量库"的理由还剩多少？（分块、Embedding 与评测闭环可参考站内另一篇《RAG 知识库搭建的 6 个工程决策》，这里只补存储层视角）下面按"事件 → 成本账 → 选型分水岭 → 决策树 → 迁移"的顺序展开。
据 InfoQ 8 月 23 日报道，这次更新推出的原生向量搜索，允许开发者将嵌入向量与应用数据存在同一张表里，直接运行近似最近邻查询，不再需要单独的向量数据库。它使用一种基于表属性中向量嵌入的新索引类型，开发者可以选任意嵌入模型（Bedrock Titan Text Embeddings、Cohere Embed、OpenAI 文本嵌入模型），创建指定维度和距离函数的索引，再用新的 SearchVectors API 查询。
几个关键能力边界：
社区反应并不全是欢呼。InfoQ 文章引用了两种代表性声音：一是"许多数据库过去几年已推出向量支持，AWS 入场太晚"的质疑；二是有开发者关心过滤器是在向量搜索之前还是之后应用，以及成本可能比 S3 这类对象存储高很多。这些质疑恰恰指向了本文要拆解的问题——托管数据库集体补向量能力，到底改变了 RAG 架构里的什么。
在这项功能之前，一条典型的 RAG 数据链路长这样：业务数据写进主库 → 同步任务把文档捞出来 → Embedding 后写入独立向量库 → 查询时先搜向量库再回主库取详情。这套架构里有三笔不显眼的隐性成本。
第一笔是第二套集群。独立向量库无论自建还是托管，都要承担副本、监控、备份、容量规划、版本升级。它是"第二个数据库"，不是"一个索引"。2026 年这份成本还在涨：InfoQ 报道 OVHcloud 因 AI 内存需求挤压产能，9 月起部分服务器涨价 40%–87%，其创始人称 6 月内存成本同比贵了 6 倍；InfoQ 中文 AI 周报也提到英伟达 AI 服务器涨价超 15%。硬件成本上涨直接抬高了"再养一套集群"的边际成本。
第二笔是同步链路。要么双写（应用侧写两遍，多一次失败点），要么走 CDC/定时任务（多一套管道要维护、要监控延迟）。
第三笔是双写一致性。向量库永远比主库慢半拍，用户问"为什么刚更新的文档检索不到"时，答案通常是"同步还没跑完"。这是 RAG 落地最常见的隐性体验问题；当记忆要长期留存时，问题会更明显，可参考《AI Agent 开发必读：智能体长期记忆的三种架构与工程取舍》。
原生向量搜索把这三笔一起抹掉：向量与应用数据同表写入，查询与写入天然一致。它的计费也透明化了——按 InfoQ 引述的官方说明，向量索引按三个维度计费：写入索引的数据、搜索时处理的数据、存储的数据，均按字节计量、按 GB 计费。官方建议的降本手段也很具体：用更低维度、减少索引投影、不在结果中返回嵌入向量、做选择性分区。这种"按字节算得清"的模型，比独立集群的预留容量账单更容易做成本预测。
两年前，企业 RAG 选型的第一问是"谁支持向量检索"，答案只有专用向量库。今天这不再是门槛——PostgreSQL（pgvector）、MongoDB、Elasticsearch/OpenSearch 等托管数据库早已内建向量能力，这次更新是又一个补齐者。第一问变成了：你的检索需求，专用向量库和托管库哪个真正满足？检索架构怎么从玩具走向工程化，可以参考站内《企业知识库 AI 检索架构进化：从玩具 RAG 到 Retrieval Harness 的工程化跃迁》。
| 维度 | 继续用专用向量库 | 直接上托管库原生向量 |
|---|---|---|
| 召回精度 | 可细调索引参数（HNSW 的 M 值、efSearch 等）压指标 | 标准 ANN，参数可控性有限，靠评测验证 |
| 过滤查询 | 复杂 metadata 过滤 + 向量距离混合，生态成熟 | 支持带过滤的相似度搜索，但过滤器前后应用语义需自测 |
| 混合检索 | BM25 + 向量融合，工具链完善 | 刚起步，融合层要自己写 |
| 部署形态 | 独立集群，可私有化/本地化 | 无服务器，随表扩展，仅云端 |
| 成本结构 | 集群资源 + 运维人力，隐性成本高 | 写入/搜索/存储按字节计费，透明但可能不便宜 |
| 一致性 | 需双写/CDC 保持同步 | 与应用数据同表，天然一致 |
结论不是"取代"，是分层：高召回、复杂过滤、混合检索、私有化部署这些硬需求，仍指向专用向量库；而以"主库即事实源、架构从简"为优先的团队，托管库第一次成为可认真评估的选项。
给正在评估的团队一张可执行的决策树（蓝曜炬辉在做 RAG 存储层选型时用的就是这个顺序）：
走完五步还落在"托管库"的，通常是中小数据量、检索需求标准、不愿意养第二套集群的企业知识库场景——这也正是当前 RAG 落地的主体，《企业知识库 AI 的三代演进：从 RAG 到 Agent 原生记忆系统》里描述的三代演进，存储层正是分水岭。
如果决定试点这套原生向量搜索，建议按三步走：
风险提示，都在第一周就会遇到（PoC 与生产之间的差距可以参考《PoC 跑通了，生产环境为什么还是崩？——企业 AI 应用的 5 道工程门禁》）：
据 InfoQ 8 月 23 日报道，向量索引已在 DynamoDB 当前提供服务的所有区域开放，支持 Standard 或 Standard-IA 表类别的表。可视为 GA 状态。
OpenSearch 主打全文 + 向量混合检索，适合已有搜索业务的企业；原生向量搜索的核心优势是同表一致性——应用数据和向量在同一张表，省掉同步链路。选择取决于你的主数据源在哪。
主流嵌入模型（OpenAI 的 text-embedding-3 系列、Amazon Bedrock Titan 等）的维度普遍在几百到三千多，低于 4096。若你使用的模型维度更高，需降维或改用专用向量库。
不建议。触发迁移的三个条件是：检索一致性频繁出问题（同步延迟导致召回陈旧）、第二套集群成本难以控制、且检索需求标准化。三者同时成立再试点。
按三个维度计费：写入索引的数据、搜索时处理的数据、存储的数据，均按字节计量、按 GB 计费。降本四招：更低维度、减少索引投影、结果不返回嵌入向量、选择性分区。