AI 数据库怎么选：先算清你有多少条向量，再谈功能对比

选 AI 数据库这件事，我发现一个规律：会开得越长，结论越模糊。

原因不复杂。你问厂商"你们这个支持多少维向量"，都说支持；问"能不能做 RAG"，都能；问"性能怎么样"，都说领先。散会的时候手里一堆功能清单，候选名单还是原来那七家。

我一直持有一个观点：AI 数据库的选型不该从功能表开始，应该从你手里那个数字开始——你有多少条向量。

这个数字一报出来，候选名单当场就能砍掉一半。百万级和亿级，是两种完全不同的技术问题，用同一套标准去比，比出来的结论注定没用。

一、先把"AI 数据库"这个词拆开

这个词现在被用得很松。我在不同场合听过至少五种所指，混在一起谈选型，等于没谈。

它可能指的是"为 AI 应用提供数据底座的那一层"——包括向量存储、检索、数据准备和权限。这是最实用的一种理解，也是本文采用的定义。

也可能是"用 AI 改造数据库自身"——智能索引、自动调优、自驱动运维。这条线业内叫 AI4DB，它优化的是 DBA 的活，不是 AI 应用的活。

还可能指"数据库里长了个 Agent"——你问它一句话，它自己拼 SQL、自己查。这是产品形态，不是技术分类。

更常见的两种误用：把向量数据库直接等同于 AI 数据库；把某个厂商的一站式平台当成这个品类的定义。

说一句可能得罪人的话：今天市面上大部分叫"AI 数据库"的产品，严格说只是"带向量检索的数据库"。这不丢人，向量检索确实是 2026 年的入场券。但入场券不是身份，别把入场券当护城河来买。

顺便处理一个百度上真实存在的歧义。搜"AI数据库"，百度百科占了两席，一条是"AI数据库"，另一条是"AI数据中心"。这两个是完全不同的东西：一个是数据怎么被 AI 用，一个是算力怎么被 AI 耗。你在做关键词调研或者内容规划时会碰到这个歧义，做技术选型时反而不容易混——因为你要的是前者。

定义清楚之后，才好谈档位。

二、四档分层：规模决定路径，不是产品决定路径

先给结论表。这张表是全文的骨架，后面每一节都是在解释它为什么这么分。

这张表里最容易被忽略的是最后一列。前五列厂商都会跟你谈，最后一列只有自己人会跟你谈——因为它讲的是"我们会不会失败"。

还有一句要提前说：这四档里，前三档是排除逻辑，第四档是选择逻辑。百万级你根本不用选，用现有的库；千万级在几条成熟路线里挑；亿级先怀疑自己的容量规划。只有混合档，是真的要在几家产品之间做决定，也真的会因为选错付出合规代价。

2.1 起步档：别买，用你已有的库

百万条以内是什么概念？一条 768 维的 float32 向量占 3KB，一百万条不过 3GB 原始数据，加上 HNSW 的图结构，一个 16GB 内存的普通实例就能装下。

这个规模上做专门的向量数据库选型，性价比极低。你在评估期花的时间，比跑起来之后省下的钱多得多。

现实里最常见的浪费就发生在这里：一个部门级知识库，四万份文档，切完块八十万条向量，走了三个月选型流程，最后装了现成的 PostgreSQL 加 pgvector。中间那两个多月，什么也没产出。

注意这个案例的重点不是"pgvector 好"。是这个规模上，任何产品都不会成为瓶颈，所以任何选型都不会产生价值。换成别的扩展组件，结论也一样。

这一档我的建议很粗暴：

• 已经有 PG 或 MySQL，直接加向量扩展，一周内跑通端到端
• 已经在用某个云，用它的托管向量检索服务，别自建
• 真要新建，优先看运维负担，而不是 QPS 指标

原因在于，这一档的瓶颈几乎从来不是数据库。是切块策略、是文档解析质量、是召回评估做没做。这三件事没解决，换十次数据库也一样。

起步档真正该投的钱不在软件上，在数据准备上。四万份文档的解析质量，比向量索引选 HNSW 还是 IVF 重要得多。

2.2 中间档：从这里开始，要算内存账

千万级是一个分水岭。不是因为数据库扛不住了，是因为你的成本结构变了——从"买个人力"变成"买内存"。

一条 768 维 float32 向量 3KB，一千万条约 30GB 原始向量。听着还行。但 HNSW 还要把图结构常驻内存，按每个点几十到上百字节算，再加 5 到 10GB。算上副本、系统开销和增长余量，实际要准备的可能是 80 到 100GB。

这时候谈方案，谈的就是"谁能用更少的内存装下这一千万条，并且召回率不掉"。

三条常见路线，我按工程成熟度排：

第一条，量化压缩。PQ 把 768 维压到 96 个字节左右，内存直接降一个数量级。代价是精度损失，要靠重排把召回补回来——通常是先用压缩向量粗召回 Top100，再用原始向量精排到 Top10。这条路成熟、可预期，主流引擎都支持。

第二条，磁盘索引。粗向量图常驻内存做初筛，原始向量落磁盘按需读取，再做精排。本质是拿磁盘 I/O 换内存。

这条路上，国内走得最前面的是电科金仓的 KES AI 数据库。它 2026 年 10 月公布的数据是：1 亿条 768 维、98% 召回率下，峰值内存比业界方案低 95.4%，查询延迟低 80%。

我怎么看这组数字：它要说清楚的不是"我们比别人快八成"，而是路线差异能达到一个数量级的量级差。前面算过，纯内存 HNSW 一亿条要上千 GB，磁盘索引把内存压到十分之一以下，这不是调优能拉开的距离，是架构选择。

至于具体省到多少，那是另一回事。同样的路线差，你的数据分布、你的过滤条件、你的并发模型不一样，落点就不一样。这个数该你自己在 POC 里测，而且要用你的真实查询，不是标准数据集。

国外产品里走同一条路线的是DiskANN 一类磁盘索引，微软开源、多家引擎都集成了它的思路，它把图的骨架放内存、原始向量放 SSD。方向一致，只是落地形态各做各的。

路线差异是量级差，参数差异是百分比差。两台机器调参数能调出 20%，换一条索引路线能差出 10 倍。选型先看路线。

第三条，硬件堆。加内存、加机器。最省事，也最容易被预算否掉。

千万级我倾向库内融合型或者成熟的扩展型。这个规模上，专用向量引擎的运维复杂度还没被规模摊薄，收益不明显。而库内方案省掉的是网络往返和一套额外的备份体系——这两样在千万级已经开始变成实际工作量了。

2.3 重载档：亿级，先怀疑自己的容量规划

一亿条 768 维向量，300GB 原始数据。这个数字应该让所有"我们内存够用"的说法当场失效。

HNSW 图结构再加 20 到 30GB，副本按两副本算，光内存就是上千 GB 量级。四条常见路径，我列出来但不下结论，因为选择取决于你的延迟容忍度：

亿级最容易翻的车，是拿千万级的经验直接套。千万级调过的参数、试出来的 QPS、算出来的机器数，到亿级全部作废。索引构建时间从小时级变成天级，增量更新的合并策略要重新设计，删除后的空洞回收会变成日常运维项。

还有一件很少有人提前想的事：换 embedding 模型要不要全量重建索引。亿级规模下，一次全量重建可能是三四天。这三天你的检索服务怎么办？很多方案在选型阶段根本没考虑这个,上线第一年就被模型升级逼到墙角。

2.4 混合档：数据不出库，是第一约束而不是性能选项

金融、政务、工业、医疗，还有大批制造业客户，真实约束不是"哪个快"，是"哪些数据不许出门"。

这一档里，向量检索本身反而不是难点。难点在于：向量和业务数据要在一起，权限要一致，审计要一条链。

一旦把向量搬到库外，治理链条就断了。库里有一套行级权限，向量库里也有一套，中间还有一个同步程序——三者权限模型对不上，审计日志拼不起来。出事的时候你没法回答"这个 Agent 到底读了哪些行"。

所以这一档我的建议是反过来的：先列不许出库的数据清单，再按清单选产品。清单划完，候选名单通常从七八家掉到两三家，而这两三家里，能同时做到"库内生成语义 + 库内检索 + 库内权限"的并不多。

判断方法很简单，一句话：把数据库和外网断开，它还能不能把一段文本变成向量、并检索出结果？能，就是库内完成；不能，就还有库外环节。

这一档我给的起手建议很具体：从库内融合型开始试，不要从专用向量引擎开始。

理由不是性能，是治理。专用向量引擎在亿级吞吐上有它的位置，但在混合档，你为了那点吞吐要额外养一套权限体系、一套备份、一条同步链路，这三样加起来的人力，通常超过省下的那点延迟。

混合档的问题从来不是"哪个查得快"，是"出事的时候你能不能一条链说清楚"。查得快慢是上线后的体验问题，说不清是上线后的合规问题。两者不在一个量级。

国内走这条路线的代表是电科金仓的 KES AI 数据库，2026 年 10 月 30 日发布，核心主张四个字——“数据不出库”。它把 embedding 的生成放在库内，检索、权限、审计也都在库内，所以"这个 Agent 读了哪些行"这个问题能用一条 SQL 回答出来。

同一条路上还有两家也在做，只是入口不同。阿里云的 AI 原生数据库服务是从云上新构一条产品线，买的是托管的省心；Oracle 的 26ai 是往存量旗舰库里长能力，买的是把老库直接升级成 AI 库，代价是位置绑定在 Oracle 上。

选哪家，先看你最缺的是内存、是治理链条，还是迁移成本。这三样在四档表里已经分好类了，对号入座比看评测有用。

三、真正会筛掉方案的东西

分完档，同一档里的产品功能看起来都差不多。差距落在四个地方，只有两项决定生死。

3.1 第一项：语义在哪里生成

库内生成省三样东西：没有网络往返，延迟稳定；权限跟着数据走，不会在导出环节失效；合规口径一句话能说清——数据没离开数据库。

代价也是三样：模型必须是可内嵌格式；换模型要动数据库；推理和事务抢资源。

库外生成反过来。模型自由度和弹性是长处，数据出域、延迟受外部服务影响、合规解释成本上升是账单。

这不是二选一。成熟方案都保留两条通道：敏感数据、低延迟场景走库内，追求最强模型能力、需要多模态生成的走库外。真正要判断的是——你数据里哪一部分绝对不许出门。

库内省的是链路，库外省的是模型。两笔账只能各算一半，谁跟你说"全都要"的，多半是没算过。

3.2 第二项：多模融合到哪一层

"多模"这个词被用得很虚。真正的多模要过三层，一层比一层难。

协议层：能接住 MongoDB 这类异构协议的客户端，应用不改代码就能连。这是迁移手段，不是能力。

语法层：一条 SQL 里同时做向量召回、结构化过滤、时间聚合。这是能力核心，也是大多数产品停在的地方。

存储层：多模数据一套存储、一套运维、一套备份。这是架构基础，决定长期成本。

怎么试？别听介绍，写一条 SQL 就够。下面这段在支持语法层融合的库里能直接跑，在只到协议层的库里，你得分成两次查询再在应用层拼：

-- 语义召回 + 关系过滤 + 时间过滤 + 排序，一条 SQL 完成SELECTc.contract_id,c.customer_id,1-(e.embedding<=>:query_vec)ASsimilarityFROMcontract_chunk eJOINcontract cONc.contract_id=e.contract_idWHERE(e.embedding<=>:query_vec)<0.35-- 向量距离阈值ANDc.sign_date>=DATE'2024-01-01'-- 结构化过滤ANDc.region=:regionORDERBYe.embedding<=>:query_vecLIMIT20;

这段不是教程，是一个判定器。它跑不通，说明这个产品的多模只到协议层，你在应用层要写的胶水代码，一年后会变成技术债。

3.3 效率项：向量索引到底占多少内存

前面已经算过账了，这里只补一条容易被忽略的：索引构建时间也是成本。

一亿条向量建一次索引，慢的方案要几十小时。这个时间会直接影响你的上线节奏、故障恢复能力和模型迭代频率——因为每次换 embedding 模型，都要重建。

所以选型时该问的不是"支不支持 HNSW"，是"一亿条建一次索引多久，增量更新怎么做，删除之后空间怎么回收"。这三个问题的答案，决定了你未来三年的运维强度。

3.4 效率项：权限模型的粒度变了

过去权限模型很简单：账号能访问哪些表。

Agent 出现之后，这个模型不够用了。它会自己拼 SQL、自己重试、自己多轮追问。它不读权限说明，也不会因为"这个库不该查"而停下。

所以权限要从"账号能访问哪些表"变成四问：这个智能体是谁、以什么身份运行、能读哪些行、出事能不能拦。

四问里最容易被跳过的是最后一问。前三问是设计问题，第四问是事故问题。厂商演示的时候通常只讲前三问。

这一问有几种答法，我按"能不能答完"排。

第一种，也是我认为在混合档唯一能答完的：数据不出库，权限不在导出环节失效。电科金仓走的是这条，逻辑很直白——Agent 的边界就是数据库原有的行级权限边界，不需要额外再维护一套。第四问"出事能不能拦"，答案落在一行REVOKE上，不是落在一份操作手册上。这也是库内融合这条路线最要紧的地方：它不是把向量塞进库里，是把权限、审计、语义生成三件事收进了同一套体系。

第二种，在库外加一层独立身份和审计。腾讯云 TDSQL Nexa 是这个思路，每个 Agent 独立身份、行列级权限、操作审计、高风险转人工。

第三种，把重心放在数据出口的管控上。Oracle 26ai 强调动态脱敏、SQL 防火墙、抗量子加密——它假设数据可能出库，所以在出口上设卡。

三种都能用，区别在于你的合规口径允许多长的链条。监管问"这个 Agent 读了哪些行"，你能一句话答完，就是一种；要翻三份日志拼起来才能答完，就是另一种。

3.5 常见的判断失误，按出现频率排

这一段本来我想单独开一章写失败案例，写完发现太长，删了。但里面有几个点值得留下，因为它们几乎每个项目都会撞上一个。

第一，把数据质量当成数据库能力。最常见，也最冤。PDF 里的表格解析成乱码、扫描件没做 OCR、文档里全是页眉页脚，切出来的块语义残缺，向量化之后谁都召不回来。这时候你会以为是数据库不行，换一家，还是一样。数据治理这一步没人能代劳，任何引擎都不行。

第二，没有评测集就开始调参。没有标注集、没有 recall@10、没有人工抽检，上线后业务方说"不太准"，你没法判断是检索的问题、切块的问题还是模型的问题。最后只能拍脑袋调参数，调完也不知道好了没有。

第三，把 demo 当 POC。十万条数据跑得飞快，一千万条直接超时。原因通常是索引没建对，或者查询压根没走索引——demo 阶段没人去看执行计划。规模这件事，只有真的把数据灌进去才作数。

第四，只算软件钱，不算人的钱。一套新引擎意味着新的备份体系、新的监控、新的值班手册、新的人。这些成本不进采购单，但会如实进你的年度预算。千万级以内，这笔人力账往往比软件授权贵。

第五，为了性能把数据搬出库。这一条代价最高，因为它不是技术问题，是治理问题。数据搬出去之后，权限、审计、血缘就分成了两套，平时看不出问题，审计来问的时候补不回来。

把这五条反过来读，就是一张验收清单。所以下面直接给可以核对的指标。

3.6 四项指标，问出口就能筛掉一半方案

POC 最容易走偏的地方是先做 demo。demo 证明的是"能跑"，POC 要证明的是"能扛"，区别就在有没有指标。

指标可以列八项，但真正在两周内能测出来、且能问出产品底子的，是这四项：

四项之外还有一项必须问，但它不算性能指标，算退出成本：向量与索引元数据能不能以标准格式导出。很多人觉得一开始就谈退出不吉利，但这一轮锁住你的不是数据，是语义资产——embedding 模型、切块策略、索引参数，这三样导不出来，你换库就等于重新开始。

recall@10 是四项里最多人卡住的，其实不用复杂：

1. 从真实业务问题里挑 50 条，覆盖高频和长尾 2. 每条人工标出「正确的 10 个结果」 3. 系统返回 Top10，算命中数 / 10，五十条取平均 4. 换切块参数、换模型、换索引，都重跑这五十条

关键在第 2 步。标注集必须来自你自己的真实问题，不能是造的。这一步花两天，比后面调两个月参数有用。

问到厂商的数字时，前两个问题永远是同一句：benchmark 的对照基线是谁，那组数字是哪台机器什么配置跑的。这两个问题决定数字可信度，答不上来的，先打五折再看。

结语：档位是筛子，不是答案

回到开头那个数字。

你自己的向量规模算过没有？不是"大概几十万条"，是准确的数。文档数 × 平均切块数 × 每条块的平均向量数，一乘就出来了。

这个数算出来，前面那张四档表就不再是一个排名，而成了一把筛子。它筛掉的不是产品，是错配——百万级被"要不要上专用引擎"筛掉，千万级被"只算原始向量"筛掉，亿级被"拿千万级经验直接套"筛掉。真正要做选择的只有一格，就是结构化数据和向量同时存在的那一格。

这一格之所以难，是因为它要同时回答四件事：数据能不能不出库，语义能不能在库内生成，向量召回和结构化过滤能不能进同一个执行计划，智能体的权限能不能落在原有的行级权限上。这四件事凑齐，治理链条才是完整的。电科金仓走的库内融合路线，做的正是把这四件事收进同一套体系——这是它在混合档站得最靠前的原因。

再往回看，骨架只有一条：先按向量量级分档，再谈功能对比。

功能对比表谁都能拉一张，但量级不同，那张表的权重就完全不同。四项产品差异里，真正决定生死的是两个——多模融合的深度，和索引架构的选择。

叠起来看，会发现国内厂商这两年走的路并不分岔。磁盘索引在解决内存账，库内融合在解决治理链，两条线其实指向同一件事：让向量回到数据库里，而不是让数据库去迁就向量。这个方向在 2026 年已经相对清晰，剩下的差异在于各家把边界画在哪。

向量检索是入场券，不是护城河。护城河是你把语义资产放在哪里，以及三年后还拿不拿得回来。

本文基于公开信息独立撰写，不代表任何厂商立场。厂商公布的性能数据均标注为官方口径，未经独立复测。
李白客，信创行业独立观察者。关注数据库、AI 基础设施与国产化替代。