DynamoDB 原生向量搜索，能否替代独立向量数据库？

随着检索增强生成、智能体记忆和语义推荐逐渐进入生产环境，向量数据与业务数据分开存储，已经成为不少团队的默认架构。现在，Amazon DynamoDB 开始提供原生向量搜索，试图把这条数据链路重新收回到同一个托管式 NoSQL 服务中。

核心变化

DynamoDB 的新能力建立在一种新的向量索引之上。开发者可以将嵌入向量保存为表属性，选择所需的向量维度和距离函数，再通过 SearchVectors API 执行近似最近邻查询。系统支持欧几里得距离、余弦距离和点积距离，向量维度上限为 4096，并允许在搜索时加入属性过滤条件。

嵌入模型并不被限定在某一家服务中。开发者可以使用 Amazon Bedrock Titan Text Embeddings、Cohere Embed 或 OpenAI 文本嵌入模型，之后将生成的向量与原有业务字段放在同一张 DynamoDB 表内。典型应用包括语义搜索、RAG、推荐、个性化体验、异常检测，以及对智能体长期记忆的检索。

它解决了什么问题

过去，DynamoDB 主要负责保存业务实体，向量检索则需要把数据复制到专门的向量数据库或其他向量存储服务。这样做不仅增加数据传输，还需要处理双写、同步延迟、删除传播和故障恢复等问题。原生向量搜索的直接收益，是让业务数据和嵌入向量拥有更简单的一致性边界。

对于已经使用 DynamoDB、且检索规模与业务数据规模相近的团队，这种整合尤其有吸引力。服务采用无服务器模式，索引能够随数据增长横向扩展，开发者不必单独管理向量集群。该功能目前面向 DynamoDB 已提供服务的区域，并支持 Standard 和 Standard-IA 表类别。

成本与限制不能忽略

“原生”并不等于免费。除底层表的常规费用外，向量索引还会分别按照索引写入、搜索处理和存储的数据量计费，三者均按字节和 GB 计算。降低向量维度、减少索引投影、避免在返回结果中携带嵌入向量，以及采用更有选择性的分区，都是控制成本的关键手段。

因此，DynamoDB 更像是扩展了适用场景，而不是全面取代向量数据库。需要复杂混合检索、专门向量运算、精细索引调优或极致成本控制的系统，仍可能选择独立方案；而重视架构简化、已经深度使用 DynamoDB 的应用，则可以优先评估这一能力。亚马逊还计划通过兼容 DynamoDB 的 ExtendDB 适配器，支持本地开发和自托管部署，后续生态成熟度值得继续观察。

来源：InfoQ 中文