夜雨聆风今年有些数据库厂商已经开始全面进军AI数据库方向，很多数据库厂商虽然喊着AI数据库，不过从目前公布的能力来看，口号多一些，从内核原生能力上看，还不是十分亮眼。
提起AI数据库，Oracle绝对是先驱，虽然被很多“大明白”一直吐槽“屎山代码”已经改不动了，但是在AI转型方面，我并没有看到“改不动”的迹象，通过全面的比对分析，Oracle在AI能力方面还是标杆式的存在，值得国产数据库厂商全面学习。
在一份分析报告里我无法对所有的国产数据库做一个全面比对，所以我只选出了在AI能力方面我觉得能够和Oracle有一战之力的两个数据库来应战Oracle。因此在本报告中有三个数据库产品：Oracle 26ai 的 AI 能力已经历多个 23ai/26ai 更新迭代；OceanBase 的向量能力从 4.3.3 开始发展；YashanDB 23.5.4 则是刚发布的首个 AI Edition。
使用的对比材料来自于各个厂商的官网：
Oracle：Oracle AI Database 26ai / Autonomous AI Database 26ai
OceanBase：OceanBase Database 4.6.x、OB Cloud 及 seekdb
YashanDB：2026 年 7 月 7 日发布的 v23.5.4.100 AI Edition
实际上这三种数据库，我只针对崖山做过真实的测试，其他两种完全根据文档。可能大家会发现针对YashanDB的一些描述会更加细致一些，和这个是有一定关系的。Oracle的AI能力虽然我没有亲自测试，不过我一直在关注相关的技术发展，Oracle Concepts我也做了一些阅读。而Oceanbase的一些能力分析则借助了AI手段，因为目前4.6版本在我的实验室中尚未安装部署。因此针对OB的一些描述可能会存在理解不足的问题，如果有朋友发现，多多指正。
后面的比对表格很长，因此先谈谈我对这三种数据库的AI能力的感受，如果没有时间全面阅读的朋友，看完下面的总体评价，就可以收藏一下，以便于后续慢慢阅读了。
Oracle 26ai 综合能力最完整、成熟度最高，已从向量数据库扩展到混合搜索、数据库内模型、RAG、NL2SQL、AI Agent、MCP、身份传递和细粒度数据安全，形成了较完整的企业 AI 数据平台。
OceanBase 当前最强的是分布式混合搜索和 AI 应用工程化，OceanBase 4.6/seekdb 在“向量＋全文＋标量＋JSON”的混合搜索、分布式扩展、AI Functions 和国内模型生态方面很有竞争力。它更像面向互联网及云原生 AI 应用的高扩展搜索数据底座，但数据库内 Agent、NL2SQL 和端到端安全治理尚未达到 Oracle 的完整程度。
YashanDB 23.5.4 功能设计非常激进，部分架构亮点甚至比 OceanBase 更丰富，全面对标了Oracle，它一次性提供了向量、全文、图、JSON、空间、文件、时序、多模联合查询、模型管理、AI Functions 和数据分支。尤其是“向量＋图＋关系”联合查询以及面向 Agent 的数据分支很有特色。但该版本刚刚发布，生产案例、性能边界、客户端生态和长期稳定性仍需验证。
能力维度 | Oracle 26ai | OceanBase 4.6 / seekdb | YashanDB 23.5.4 AI Edition |
原生向量类型 | 支持稠密、稀疏及多种向量格式 | 支持原生向量类型 | 支持原生向量类型，支持 VECTOR(n, format)，FLOAT32 /FLOAT64，最高声明维度65535 |
精确向量搜索 | 支持 | 支持 | 支持 |
ANN索引 | HNSW、IVF | HNSW为主 | HNSW |
距离度量 | 欧氏距离、余弦、点积等 | 欧氏距离、余弦、内积等 | 欧氏距离、欧氏距离平方、余弦、内积 |
稀疏向量 | 支持，HNSW已支持SPARSE | 公开能力相对有限 | 当前官方文档主要描述稠密FLOAT向量 |
向量与关系过滤 | 支持，优化器集成较成熟 | 支持标量、JSON与向量组合过滤 | 支持B+树与HNSW协同及“先过滤、再检索”， 支持标量、JSON、图等与向量组合过滤 |
全文＋向量混合搜索 | 原生 Hybrid Vector Index，单一索引完成分块、嵌入、全文和向量索引 | 原生混合搜索接口，融合全文、向量、标量等结果 | 可在统一SQL中组合全文与向量，但当前示例更接近查询级融合 |
文档自动分块 | DBMS_VECTOR_CHAIN、Hybrid Vector Index、Select AI RAG原生支持 | 有文档/RAG工具链，数据库内完整度依版本和产品形态而异 | 现有文档重点在向量和AI函数，自动分块流水线不如Oracle明确 |
数据库内Embedding | 支持ONNX模型在数据库内推理，也可调用外部服务 | AI Function调用注册的Embedding模型 | AI_EMBED调用已注册Embedding模型 |
数据库内LLM生成 | Select AI和数据库包支持调用多种LLM | AI_COMPLETE等AI Functions | AI_COMPLETE、AI_GENERATE |
Rerank | 可通过RAG链、外部模型和应用流程实现 | AI_RERANK，属于混合搜索的重要组成 | 原生AI_RERANK函数 |
模型管理 | AI Profile、ONNX模型、外部Provider配置，体系最完整 | AI模型注册、API Key和模型服务管理 | DBMS_LLM管理Embedding、Rerank、LLM三类模型 |
原生RAG | Select AI RAG，可管理向量索引、分块、来源和相似度阈值 | 支持RAG构建，seekdb、OB Cloud及LlamaIndex/Dify集成较成熟 | 具备构建RAG的底层组件，但尚未看到与Select AI同等完整的RAG管理层 |
NL2SQL | Select AI原生支持，包含对象选择、约束、反馈和会话 | 主要由AI助手/OAgent或应用层完成 | 通过独立的服务组件YAS AI Helper提供NL2SQL的能力，已规划内核原生Select AI能力 |
AI Agent | Select AI Agent支持Agent、Task、Tool、Team | OB Cloud具有OAgent，但更偏云服务及应用平台层 | 数据分支非常适合Agent实验，但尚未看到完整Agent编排框架 |
MCP | Oracle Database Tools MCP Server、Autonomous AI Database MCP及SQLcl MCP生态 | 可通过应用生态对接，数据库原生MCP能力暂不及Oracle完整 | 发布了MCP服务，可以通过应用生态对接 |
AI访问安全 | IAM身份传递、Deep Data Security、行列单元级权限、审计 | 继承OceanBase租户、权限和审计体系，但Agent身份传递能力较弱 | 权限、审计及数据分支隔离较有特色，但缺少Oracle式Agent端到端身份链 |
分布式扩展 | RAC、分片、Exadata、Autonomous等，但架构和成本较重 | 原生分布式是核心优势，更适合大规模在线混合负载 | 支持单机、主备、共享集群、分布式，AI版本的规模化验证较少 |
I融合 | Oracle Property Graph、SQL/PGQ、向量及图分析体系成熟 | 主数据库当前AI重点不在属性图与向量联合推理 | 23.5.4明确支持SQL/PGQ及向量＋图联合查询，是显著亮点 |
AI数据沙箱 | 可通过PDB快照、克隆、Autonomous能力实现，但并非统一Agent分支接口 | 可依靠租户、克隆及云环境构建 | 原生DBMS_BRANCH、Copy-on-Write数据分支，针对Agent试错设计 |
成熟度 | 高 | 中高 | 中期 |
多模态或者多模多态能力是AI数据库的基础能力，虽然并非所有多模能力都是AI能力相关，不过其能力的强弱决定了数据库对于AI应用的一体化支撑能力，也会间接影响AI应用开发的总体成本。因此我们把多模能力作为一个单独的评估项做了全面的对比。这里的“多模态”指数据库对关系、文档、文本、向量、图、空间、时序及非结构化文件等数据模型的统一处理能力，并不等同于大模型直接理解图片、音频和视频。
多模态能力 | Oracle 26ai | OceanBase Database 4.6 | YashanDB 23.5.4 AI Edition |
关系数据 | 成熟的关系模型，支持行存、列存及分析处理 | 原生分布式关系模型，支持行存、列存及行列混存 | 原生关系模型，支持单机、共享集群和分布式部署 |
JSON文档 | 原生二进制JSON、SQL/JSON、JSON关系二元性视图、JSON索引 | 原生JSON类型、JSON函数、路径查询及索引，主要面向MySQL模式 | 原生二进制JSON、SQL/JSON函数、JSON_TABLE及JSON路径函数索引 |
XML | 完整XMLType、XML索引及SQL/XML体系 | 不属于4.6重点多模能力，完整度明显低于Oracle | 当前AI Edition公开能力重点不在XML |
全文数据 | Oracle Text，支持语言分析、主题、模糊匹配、文档过滤和多种全文索引 | 原生全文索引，支持与向量、标量条件进行混合搜索 | 原生倒排索引，支持中英文分词、布尔检索、短语及LIKE自动改写 |
向量数据 | 稠密、稀疏、二进制向量；HNSW、IVF及精确搜索 | 原生向量类型；精确搜索和HNSW近似搜索 | FLOAT32/FLOAT64向量；精确搜索和HNSW近似搜索 |
文本＋向量融合 | Hybrid Vector Index将Oracle Text和向量索引封装为统一索引 | HYBRID_SEARCH融合全文、向量和标量召回，支持RRF/WRRF | 可在SQL中组合全文检索和向量检索；具备Rerank能力 |
图数据 | SQL/PGQ属性图、图分析及RDF语义图，图生态最完整 | OceanBase Database 4.6本体暂未形成成熟的原生属性图查询体系 | 基于SQL:2023 SQL/PGQ的属性图，关系表直接映射为顶点和边 |
图＋向量融合 | 图查询可与关系和向量SQL组合，但通常需要显式设计查询流程 | 当前不是OceanBase Database本体的主要能力 | 支持图遍历叠加向量相似度过滤，是三者中非常突出的能力 |
空间数据 | Oracle Spatial、SDO_GEOMETRY、空间索引、网络模型、拓扑和GeoRaster，能力最完整 | 原生Geometry、空间函数和空间索引，可与关系、JSON等数据共同处理 | 原生Geometry、空间函数、坐标转换和R-Tree索引 |
栅格/遥感数据 | GeoRaster原生支持，适合影像、遥感和栅格空间数据 | 暂无与Oracle GeoRaster同等级的完整体系 | 暂无与Oracle GeoRaster同等级的完整体系 |
时序数据 | 通过关系表、分区、压缩、时间有效性和分析函数处理；不是独立时序引擎 | 可通过分区、列存、HTAP及时间函数处理；4.6本体未突出独立时序模型 | 深度集成时序组件，支持关系—时序联邦查询、降采样、补齐、修复及趋势搜索 |
非结构化文件 | BLOB、CLOB、BFILE、SecureFiles、DBFS及文档提取；BFILE可引用库外文件 | BLOB/TEXT及LOAD_FILE读取外部存储文件；文件不是原生事务对象 | 文件被提升为数据库对象，通过DBMS_FS管理，文件操作可与关系DML共享事务、审计和备份恢复 |
图片、音频、视频 | 可保存原文件或引用，并将内容转换为向量进行相似搜索 | 可保存原文件/元数据及其Embedding向量；数据库不直接理解媒体内容 | 可将文件原生存入数据库，并保存模型生成的向量；数据库不直接生成视觉或音频语义 |
跨模态SQL查询 | 关系、JSON、XML、空间、图、文本和向量可以在SQL中组合，覆盖面和成熟度最高 | 关系＋JSON＋全文＋向量＋空间组合较强，核心优势是全文、向量和标量混合搜索 | 支持关系、JSON、全文、向量、图和空间的跨模JOIN及谓词下推 |
统一事务一致性 | 各数据类型共享Oracle事务、安全、备份恢复和审计体系；部分外部文件除外 | 数据库存储的数据共享分布式事务和Paxos一致性；外部文件读取不属于同一事务对象 | 关系、JSON、向量、图映射及库内文件强调统一ACID、MVCC、权限和备份 |
总体特点 | 模态覆盖最广、单项能力最深、生态最成熟 | 关系、JSON、全文、向量的分布式融合最实用 | 跨模联合查询最激进，图＋向量和事务性文件最有特色 |