Native Vector Search（原生向量搜索）

早期向量检索需要专门部署向量数据库（Pinecone、Milvus、Weaviate 等），与业务数据库分离，带来数据同步、一致性与运维复杂度问题。Native Vector Search 把向量索引内置到既有数据库：向量列与关系列同表存储、同引擎查询，可在一条 SQL 里同时做向量相似度匹配与结构化过滤（如『找语义相近且价格在 100 元以下的商品』）。动机是消除数据搬运、降低架构复杂度、让向量检索复用数据库已有的事务/备份/权限体系。

两者各有适用场景。独立向量库在超大规模（十亿级向量）、极致召回/延迟调优、专用索引算法上仍领先，适合向量是核心资产的场景。原生向量搜索胜在架构简化与混合查询：向量与业务数据零同步延迟、强一致、复用既有运维能力，适合『向量是业务数据的一个维度』的大多数企业场景。DiskANN 这类磁盘级 ANN 算法的成熟，让数据库在商用硬件上即可支撑大规模向量索引，是原生化得以成立的技术前提。

2026 年出现罕见的多厂商同步推进：AWS 推出 S3 Vectors 并为 DynamoDB 增加向量搜索；Microsoft 在 SQL Server 2025 原生集成 DiskANN；Oracle 通过 GoldenGate 等推进嵌入能力（本轮 poolId N5）。这种一致性表明向量检索正从『要不要用向量库』转向『向量检索是数据库的默认能力』。对工程实践的含义：新建 RAG/记忆系统时，应优先评估既有数据库的原生向量能力是否够用，而非默认引入独立向量栈——这会显著影响架构复杂度与长期运维成本。