🗄️ 数据库 · 基础设施更新
Amazon DynamoDB 原生上线向量搜索，AI 应用可以少一条数据流水线
向量嵌入与应用数据同表存储，SearchVectors API 直接运行近似最近邻查询——最多 4096 维、个位数毫秒延迟。开发者不再需要为 AI 应用单独部署一套向量数据库。
综合公开信息•
2026-08•
全文约 4 分钟读完
#DynamoDB
#原生向量搜索
#RAG
#AI 基础设施
#无服务器
1 张表
向量与应用数据同表存储，省掉整套同步流水线
4096 维
最大向量维度，支持内联过滤
<10ms
官方延迟目标，可扩展至数万亿向量
30 秒速览
- 核心变化：DynamoDB 原生向量搜索正式上线——向量嵌入与应用数据存在同一张表，用新的 SearchVectors API 直接查询，不再需要单独的向量数据库。
- 能力边界：最多 4096 维，支持欧几里得 / 余弦 / 点积三种距离函数，查询时可内联过滤属性。
- 成本真相：向量索引按「写入索引数据 / 搜索处理数据 / 索引存储数据」三个维度计费，官方给出四条降本路径。
- 社区回声：有开发者说“入场太晚”，更多人兴奋于单表架构带来的简化；对过滤时机与成本压力的疑问同样真实。
- 可用状态：已在全部区域开放，支持 Standard 与 Standard-IA 表；本地自托管方案 ExtendDB 正在路上。
01变的是什么？一张表，少一条流水线
DynamoDB 是后端世界的事实标准之一——无数应用的会话、订单、元数据都躺在它的表里。过去两年，这些团队想做 AI 功能时，总会撞上同一堵墙：向量数据放哪？
答案往往是：再部署一套向量数据库。然后，痛苦开始了。
旧架构 · 双系统同步
- 数据复制到独立向量数据库
- 两套系统持续同步
- 额外数据流水线与传输成本
- 架构复杂度随业务膨胀
新架构 · 单表原生
- 向量与应用数据同表存储
- 直接在 DynamoDB 内跑 ANN 查询
- 移除额外数据流水线
- 无服务器自动扩展
注：左右两栏对比的是同一业务的两种数据架构。实际迁移时，还需要额外评估索引重建成本与查询延迟表现。
DynamoDB 新增的其实是一种新索引类型——向量索引。它基于表属性中存储的向量嵌入构建，开发者可选择任意嵌入模型（如 Bedrock Titan Text Embeddings、Cohere Embed 或 OpenAI 文本嵌入模型），自定义维度与距离函数，然后通过新的 SearchVectors API 发起查询。
这不是在 DynamoDB 旁边加了一个向量组件，而是把向量搜索变成了 DynamoDB 本身的属性。
02为什么可信？官方口径与架构细节
官方口径相当直接。亚马逊云科技首席解决方案架构师 Esra Kayabali 写道：
“向量索引没有存储限制，并会随着数据增长进行横向扩展。现在，你可以利用 DynamoDB 及其原生向量搜索功能，构建需要对智能体记忆进行语义检索、检索增强生成、推荐引擎、个性化体验和异常检测等功能的应用。”
🧩 选嵌入模型→
🏗️ 建向量索引→
📥 写入同表→
🔎 SearchVectors API
注：链路中的每一步都在 DynamoDB 表内完成。距离函数三选一：欧几里得 / 余弦 / 点积，均可叠加内联过滤。
性能标尺同样明确。亚马逊云科技副总裁 Jeff Barr 在 LinkedIn 上强调：
“可以扩展到你需要的任意规模——想想数万亿个向量——同时保持个位数毫秒级延迟。”
—— 亚马逊云科技副总裁 Jeff Barr
03成本账单免费的功能，不免费的索引
“原生支持”四个字很诱人——少一套系统，少一份同步的苦。但它不等于免费。除了底层表的标准 DynamoDB 费用，向量索引会按三个维度计费。
💾
写入索引的数据向量写入时产生，按字节计量
GB 计费
🔍
搜索时处理的数据每次查询扫描的数据量，按字节计量
GB 计费
🗄️
索引存储的数据向量索引占用的持久化存储，按字节计量
GB 计费
注：三路费用均按字节计量、按 GB 结算。总成本与写入频率、查询热度和索引体积高度相关，无法简单地用“每个请求多少钱”概括。
要控制账单，官方给出了四条路径。
📉 降低维度低维向量直接减少存储量与计算量
✂️ 减少投影索引只保留必要属性，缩减体积
🙈 不返回嵌入查询结果不携带向量，减少传输数据
🗂️ 选择性分区按业务维度隔离，控制扫描范围
官方称这些是“能够显著降低向量搜索成本的主要方法”——换句话说，成本优化的责任，在开发者这边。
你省下的是架构复杂度，付出的是更精细的成本管理。
04它能做什么？从 RAG 到智能体记忆
能力是新的。但它到底能做什么？
📚 RAG 语义搜索官方演示
- 用 Bedrock 嵌入 + DynamoDB 构建 Python 语义搜索应用，按语义而非精确关键词查找相关研究论文
- 论文全文与向量同表存储，元数据查询与向量检索无需跨系统
- 对知识库问答类应用，这是最直接受益的场景
对 RAG 场景，最大的价值不是“能做”，而是“少接一根管道”。
🧠 智能体记忆检索官方原话
- 支持对“智能体记忆”进行语义检索，是官方明确列出的目标场景
- Agent 的记忆与应用数据同表，天然保证状态一致性
- 写入与召回在同一张表内完成，延迟更可控
智能体应用的“记忆一致性”一直是工程难点，单表方案把这件事简化了一档。
🚨 异常检测与风控典型场景
- 向量空间中的离群点检测，可用于交易风控与系统告警
- 业务数据与向量同表，异常上下文完整可查，无需跨系统 join
- 内联过滤可叠加业务维度，如用户、地域、时间窗口
这类场景过去需要拼接多套系统，现在一张表就能跑通。
05诚实的边界不是所有人都买账
故事的另一面，同样值得看。
一些从业者认为亚马逊云科技“入场太晚”——过去几年，已有不少数据库陆续推出向量支持。但更多声音认同这项功能的真实价值。开发者 Humayun Khan 评论：
“DynamoDB 原生向量搜索可以将向量搜索和应用数据保存在同一个位置，从而大幅简化 AI 应用的构建。”
也有开发者关心更具体的实现问题。
过滤条件在向量搜索之前还是之后应用？
官方报道未给出明确说明。两种顺序对召回率与延迟的影响不同，社区仍在测试验证。
和 S3 向量存储桶比，DynamoDB 的成本劣势有多大？
开发者 coinclick 的提醒：S3 近乎无限扩展、延迟稳定但不算出色；DynamoDB 扩展好、延迟极低，但成本可能比 S3 高很多。
⚠️ “取代”需要打一个折扣——DynamoDB 的原生向量搜索确实简化了架构，但账单、延迟与过滤语义的权衡，会让一部分重度工作负载继续留在专用向量数据库里。
选型从来不是只看功能，而是看账单、延迟与复杂度的三角平衡。
编辑核心判断
DynamoDB 原生向量搜索的真正信号，不是“又一款数据库支持了向量”，而是向量搜索正在从一种需要单独采购的能力，变成数据库的默认属性。独立向量数据库的窗口期正在收窄——但成本曲线和生态惯性会保护它们一段时间。最终决定去留的，不是谁的功能列表更长，而是谁能把 AI 基础设施的总账单压得更低。
▶现在就能用
登录 AWS 控制台，为现有 DynamoDB 表创建向量索引，即可通过 SearchVectors API 开始语义搜索。本地开发与自托管部署，可关注官方适配器 ExtendDB。
AWS 控制台 → 创建向量索引