AI 数据库分类笔记：六类路线、代表产品，以及我踩过的三次判断失误

去年到现在，前后参与过三个数据底座的选型讨论。回头看，错的地方不在技术参数，在于一开始就没分清「AI 数据库」这四个字到底指哪一种东西。这篇把当时的判断过程整理成一篇笔记，附六类方案的对照表。

起因

去年第一次被拉进这种会，需求是「给知识问答系统选一个 AI 数据库」。

会议室里坐了四拨人。业务方说的是「要能问得准」，厂商说的是「支持十亿级向量、毫秒级响应」，运维问的是「要不要新加一套集群」，采购问的是「为什么不能直接用现在这套」。

四个问题都对，但不在同一层。会开了一个半小时，谁也没说服谁。散会之后我回去查资料，发现问题的根源在一个词上——「AI 数据库」这四个字，在这个屋子里至少被当成五样东西用。

所指	含义	说明
为 AI 应用提供数据底座	向量存储、语义检索、数据准备、权限管控	最实用的一种理解，本文按这个定义走
AI4DB	智能索引、自动调优、自驱动运维	优化的是 DBA 的活
库内 Agent	一句话进去，自动拼 SQL、自动查、自动修	产品形态，不是技术分类
向量数据库	只解决相似度检索这一段	最容易被等同于 AI 数据库
厂商平台	采集、解析、知识工程、Agent 开发打包成服务	这已经不是数据库了

词理清了，会就好开了。把方案按技术路线归成六类，前五类差别在数据模型，第六类差别在 AI 算在哪。

第一类：关系型数据库——基本盘

企业里真正跑着 AI 应用的数据，八成还在关系库里。这个事实很容易被忽略，因为讨论的时候大家都在聊新东西。

主流产品

产品	定位	备注
金仓 KES	国产关系型数据库主力产品	2026 年 10 月发布 KES AI 数据库版本，把语义构建、计算推理、安全管控做进内核，主张「数据不出库」
MySQL	开源关系库，生态最大	中小规模系统的默认选择
PostgreSQL	开源关系库，扩展性最强	pgvector 让它在 AI 场景里重新活跃
Oracle Database	商业关系库，功能最全	26ai 版本把向量检索与模型调用收进内核
SQL Server	微软商业关系库	与 Windows 体系、Azure 生态结合紧
达梦 DM	国产关系型数据库	政务、金融存量场景覆盖广

功能特点

结构化数据、强事务（ACID）、成熟的 SQL 生态。近两年的共同变化，是往库里加三样东西：向量类型、语义层、库内推理。加完之后，关系库从「存业务数据的地方」变成了「AI 应用能直接取数的地方」。

金仓这条路线我当时花了比较多时间看。它 10 月 30 日发布的 KES AI 数据库分三层：

• 库内语义构建：把表名、字段、业务口径整理成大模型能读懂的语义层；
• 库内计算推理：内嵌 ONNX Runtime，SQL 到推理全程在库内闭环；
• 库内原生安全管控：数据不离开数据库，权限不失效。

官方公布的实测条件是 1 亿条 768 维向量、98% 召回率，该条件下峰值内存开销较业界降低 95.4%，查询延迟降低 80%。

这三层里，我最初以为最麻烦的是第二层（内嵌推理），后来发现是第一次：语义层。它不涉及什么高深技术，就是把表名、字段、指标口径的含义一条条梳理清楚，而这个活只能人干。当时那个项目的 NL2SQL 准确率一直卡在四成多，查了两周才发现不是模型问题，是字段注释写得随心所欲，同一个「金额」在三张表里指三种口径。

使用场景

• 存量业务系统接 AI：客服知识问答、合同要素抽取、工单智能分派、报表自然语言查询。
• 数据敏感度过不了「数据出域」评审：政务、金融、医疗、能源。
• 不想为 AI 再建一套数据底座的团队。

第二类：NoSQL 数据库——非结构化数据的主场

AI 应用里所有「不是表格」的东西，第一站基本都在这。

主流产品

产品	类型	特点
MongoDB	文档型	存 JSON 格式的业务对象，schema 灵活；Atlas 版本已支持向量检索
Redis	内存键值	亚毫秒级读写，做缓存、会话、实时排名
Elasticsearch	搜索引擎	倒排索引 + BM25，全文检索默认选项；8.x 起支持向量字段，能做混合检索
Cassandra / HBase	宽列	大规模写入、高可用，做日志与时序底座

功能特点

模式灵活、横向扩展强、天然分布式。在 AI 链路上的位置很具体：ES 负责关键词召回，向量库负责语义召回，两者混合再加一层重排，这是目前 RAG 最常见的检索架构。

这里我记一个当时调了很久的细节：两路召回的分数不能直接加权求和。BM25 的分值和余弦相似度量纲不同，直接相加的结果是被其中一路完全主导，表现出来的现象是「改权重没用」。后来改成先归一化，或者用倒数排名融合，排序才正常。

短板在事务和强一致。不适合当账本，适合当检索入口。

使用场景

• ES：企业知识库第一级召回、日志分析、站内搜索。
• Redis：Agent 会话状态、工具调用结果缓存、限流。
• MongoDB：内容型业务对象（商品、文章、用户画像），schema 需要快速迭代的场景。
• Cassandra：埋点、监控、海量写入流。

第三类：向量数据库——最火的一类

主流产品

产品	形态	特点
Milvus / Zilliz	开源 + 云服务	国内使用最广的独立向量库，支持 HNSW、IVF、DiskANN 等多种索引
Qdrant	开源 + 云服务	Rust 实现，过滤检索性能好，payload 过滤灵活
Weaviate	开源 + 云服务	内置模块化向量化，混合检索做得顺
Pinecone	全托管 SaaS	免运维，按量计费，海外项目常用
pgvector / Oracle 向量类型	关系库扩展	不单独建库，向量和业务表放在一起

功能特点

核心三件事：embedding、ANN 索引、topK 检索。

真正决定成本的是索引选型：

索引	内存	延迟	适合
HNSW	高，全量常驻 + 图结构	低	向量总量可控、延迟敏感
IVF 系列	中，靠聚类桶控制	中	按召回率调 nprobe
DiskANN	低，磁盘为主	中高	亿级以上、预算被内存卡死

我第一次做容量估算时就漏了一块：1 亿条 768 维向量按 float32 算是 300 GB 量级的裸数据，HNSW 还要额外存图结构，常驻内存翻倍是常事。当时按裸数据报了配置，上线前重算才发现差了一倍。

另外关系库把向量类型做进内核之后，「再单独维护一套库」的必要性下降了。 数据要同步、权限要重做、一致性要应用层自己保证，这三件事的长期成本往往比省下的那点性能更贵。

使用场景

• 向量上亿、QPS 高、与业务主库关系弱：以图搜图、以文搜图、推荐召回层、代码语义检索。
• 已经在用且跑得动的系统没必要迁。
• 向量只有几十万到几百万条、还要和业务表联合过滤时，关系库的向量扩展就够。

第四类：图数据库——关系比数据本身值钱

图库在 AI 里的位置，2025 年之后被重新定价了，原因是 GraphRAG。

主流产品

产品	特点
Neo4j	图数据库事实标准，查询语言 Cypher，生态与工具链最完整
NebulaGraph	国产开源分布式图库，支撑超大规模图
ArangoDB	多模数据库，一份数据支持图、文档、键值三种模型
TigerGraph	面向大规模图计算，偏分析型负载

功能特点

数据模型是节点和边，查询方式是遍历而不是 join，多跳关系查询优势明显。

AI 场景里的价值有两块：知识图谱给大模型提供结构化领域知识，GraphRAG 把「实体—关系」抽出来建图，解决纯向量检索找不全跨文档关联的问题。

使用门槛高：图 schema 怎么设计、实体怎么抽、抽取错了怎么修，都需要人。它不是买回来就能用的东西。这一点在做项目排期时必须算进去，我们当时的估算是低估的。

使用场景

• 反欺诈（资金网络、交易环路识别）、推荐（社交关系、兴趣扩散）。
• 企业知识图谱：供应链、股权、合规关系。
• GraphRAG：法规条文、医疗诊疗路径、设备故障树这类强关联知识。

第五类：时序数据库——不直接服务大模型

这一类不服务大模型，但工业 AI 和智能运维的输入全在这儿。它的 AI 价值在预测，不在生成。

主流产品

产品	特点
InfluxDB	专为时序设计，写入吞吐高，查询语言 Flux
TimescaleDB	基于 PostgreSQL 的时序扩展，能直接写 SQL
TDengine	国产时序库，物联网与工业场景覆盖广
Prometheus	云原生监控事实标准，配合 TSDB 长期存储

功能特点

针对「时间戳 + 数值」做专门优化：高压缩比、时间窗口聚合、降采样。

AI 结合点在异常检测和趋势预测：设备振动数据预测故障、监控指标做容量预测、能耗数据做优化。这里的 AI 多半是传统机器学习模型，不需要大模型掺和。

通用性有限。时序库的主场是时序数据，业务表还是交给关系库。

第六类：AI 原生数据库——这一轮真正的新增量

前五类差别是数据长什么样，这一类差别是 AI 算在哪。

主流产品

产品	路线	核心主张
金仓 KES AI 数据库	库内融合	数据不出库，AI 也能用；语义构建、计算推理、安全管控三层全在库内；配套 KES MCP、Agent Skills、NL2SQL 智能体与运维智能体
Oracle AI Database 26ai	库内融合	向量检索、模型调用进内核，重心在生态接口与硬件加速
腾讯云 TDSQL Nexa	平台延伸	一个入口连多源数据，向 Agent 提供业务语义与权限治理
阿里云 AI 原生数据库服务	平台延伸	Data Agent 矩阵，覆盖采集、分析、运维、资产
华为云 GaussDB（Agent-Native 方向）	平台延伸	数据库与智能体框架协同，面向企业 Agent 落地

功能特点

分水岭只有一条：语义在哪里生成。

• 库内融合型：文本切分、向量化、相似检索、模型推理全在数据库内核完成，数据不出库。判断方法很简单——把数据库和外网断开，它还能不能把一段文本变成向量、并检索出结果？
• 平台延伸型：数据库厂商往上游长出来的平台，卖的是「知识库多久能上线」「Agent 怎么接」，而不是「每秒多少 QPS」。

库内融合这条路，落到工程上是三件事：

1. 语义构建：把表名、字段、业务口径整理成模型能读懂的语义层。这是 NL2SQL 和 RAG 准确率的天花板所在——榜单上 80% 以上的准确率，和自己在库里跑出来的 40% 多，差的通常不是模型版本，是这一层没人建。
2. 计算推理：内嵌 ONNX Runtime，SQL 里直接调模型，中间不落地、不出库。省掉的是数据在网络上的往返和一次权限失效的可能。
3. 安全管控：权限在库内生效，审计在库内留痕。Agent 不读权限说明，它只读数据——这一条过不了，前面所有能力都是空的。

使用场景

• 对数据出域有硬约束的行业：政务、金融、医疗、能源、国防军工配套。
• 想把 AI 接进存量业务系统、又不想把数据搬来搬去的团队。
• 一站式需求强、不想自己拼链路的场景。

我的三次判断失误

这部分是复盘，按发现时间排，也算给后面遇到同类问题的人留个参照。

第一次：把向量检索当成了 AI 数据库的全部。
当时的判断依据是「检索要准就得用专门的向量库」，于是把所有精力放在选哪个向量库上。做了一轮 POC 才发现，检索准不准的瓶颈在数据准备——切分策略、字段口径、权限过滤，这些都在向量库之外。向量检索只是其中一段能力，长期价值取决于语义资产建在哪、权限和一致性由谁兜底。

第二次：为 AI 单独建了一套数据底座。
结果是同一份业务数据在两个地方，同步任务写了三个，口径对不齐的时候排查要跨两个团队。数据要同步、口径要重对、权限要重做，这三笔账在采购单上看不到，在运维台上天天看见。

第三次：用功能清单做决策。
功能表上「支持向量检索」这一项，报方案的厂商全打了勾。差别不在这行勾，在于谁的检索结果和业务口径对得上、谁在线上一年的故障次数更少。后来我把问题换成「去年这条链路上出过几次故障、怎么修的」，问出来的东西才有用。

六类方案对比总结

类型	代表产品	适用场景	优势	局限
关系型数据库	金仓 KES、MySQL、PostgreSQL、Oracle、SQL Server、达梦	事务处理、结构化数据、存量系统接 AI	生态成熟、ACID 强、金仓这类库内融合路线能做到数据不出库	超大规模非结构化场景要配合其他类型
NoSQL 数据库	MongoDB、Redis、Elasticsearch、Cassandra	非结构化数据、缓存、全文检索、日志	模式灵活、扩展性强、高性能	事务与强一致弱，不适合当账本
向量数据库	Milvus、Qdrant、Weaviate、Pinecone	亿级向量检索、以图搜图、推荐召回	向量检索专用、索引选择多、性能天花板高	与业务表割裂，同步、权限、一致性要应用层自建
图数据库	Neo4j、NebulaGraph、ArangoDB、TigerGraph	关系分析、知识图谱、GraphRAG、反欺诈	多跳查询快、关系表达力强	建模门槛高，抽取和修图要人
时序数据库	InfluxDB、TimescaleDB、TDengine、Prometheus	设备监控、指标分析、工业 AI	高压缩、时间窗口聚合高效	通用性差，只适合时序
AI 原生数据库	金仓 KES AI 数据库、Oracle 26ai、TDSQL Nexa、阿里云 AI 原生数据库服务、华为云 GaussDB	数据不能出域的 AI 应用、知识问答、Agent 取数	语义、推理、安全三层都在库内，链路最短	独立成类时间短，生态还在完善
数据仓库 / 湖仓	Snowflake、BigQuery、Redshift、StarRocks	大规模分析、BI、模型训练数据准备	分析性能强、与 BI 工具集成好	不适合事务与高频点查，实时性弱

四步判断，按这个顺序问

走过一次弯路之后，我把问题顺序固定下来了：

先问数据出不出得去。 这是第一道闸。金融、政务、医疗的项目里，数据出域过不了评审，后面所有性能对比都没有意义。能出域，选择面宽；不能出域，候选名单立刻只剩库内融合这一类。金仓这条路线在政企场景里落地快，核心原因不是性能数字，是它把「数据不出库」写成了架构前提，而不是一个可选项。

再问向量有多少条。 这个数字报出来，候选就能砍掉一半。

向量规模	现实做法	别做什么
百万级以下	用现有关系库的向量扩展就够	别单独建向量库，运维成本远大于收益
千万级	关系库向量扩展或轻量向量库，算清内存账	别默认 HNSW，先算 768 维常驻内存的总量
亿级	独立向量库或库内融合方案，索引选型要看曲线	别用压事务的方法压向量检索，尺子拿错了
亿级 + 强事务 + 不出域	库内融合这类路线，一个库解决	别拼三套系统再自己维护一致性

然后问语义在哪一层。 语义在应用层，灵活但每接一个新业务就要改一次代码；在平台层，统一管理但多了一跳，权限要重新映射；在库内，口径和数据在一起，权限天然生效。

最后问失败代价能不能承受。 这一步定的是路线，不是产品。数据量够大（至少千万级）、问题够具体、失败代价可控，就先做 POC，别做 demo。demo 是挑最好看的数据跑通一次，POC 是拿最脏的数据跑三个月。这两件事的结论经常相反。

结语

回到第一次那场会。如果重开一次，我会先花十分钟把「AI 数据库」这个词拆开，让四拨人先就「我们讨论的是哪一种」达成一致，再谈产品。

答案不取决于厂商发布会的排场，取决于三个自己的数字：数据能不能出域、向量有多少条、语义资产准备放在哪一层。这三个答完，六类里能留下的一般不超过两类。

AI 数据库这轮竞争，比的不是谁功能多，是谁的链路短。链路每多一跳，就多一次数据同步、多一次权限映射、多一个故障点。金仓把语义、推理、安全都收进内核，本质上是在减链路，这也是它在政企、金融这类对合规敏感的行业里被选中的真实原因——不是因为它功能表上多了几行。

分类是为了让你少比几项，不是为了替你下结论。真要动手，先拿一个千万级、问题具体的场景跑 POC，跑完再谈采购。