OceanBase 是 100% 根自研的一体化分布式数据库，于 2010 年诞生，至今已有 16 年。在分布式数据库领域，我们一直在探索如何将理论与工程结合，也在引领行业发展——例如构建三地五中心架构、同时打破 TPC-C 和 TPC-H 测试世界纪录。

今天的报告将聚焦 AI 数据库的技术趋势与产品方向，并分享我们在全球化布局上的若干思考与探索。

想了解 OceanBase 在产品技术核心竞争力及不同行业解决方案和最佳实践，可下载

《OceanBase 一体化分布式数据库》

AI 将如何重构数据库？

当下，AI 浪潮正席卷各行各业。无论是应用开发、底层推理，还是数据库领域，所有人都在追问同一个问题：有了 AI，数据库还有存在的必要吗？ 如果答案是肯定的，那么 AI 时代的数据库，又将走向何方？

对此，我们也经历了漫长的探索与思考。我个人亲自尝试用 AI 辅助编程，测试能否借助它来构建一款数据库产品。最终的结论是：即便使用当前最强的模型，投入大量的提示词工程与技能调优，距离打造一款真正工业级的产品，差距依然相当悬殊。 但与此同时，我们也清晰地看到——AI 必将深刻重塑未来数据库的设计范式。

在我看来，这场变革最核心的，有以下两点根本性转变。

其一，数据处理的边界正在重构。传统数据库以处理结构化数据为核心使命，而随着 AI 的深度融合，大量数据处理将直接在事务型（TP）系统内完成。

其二，Agent 的崛起将催生新一代数据库。过去，数据库主要服务于特定的业务应用，未来，随着 Agent 的全面普及，数据库将迎来一次彻底的系统性升级。这不仅是功能层面的迭代，更是一次换代机遇——那些既能高效处理事务、又能原生支撑 Agent 运行的新型产品，有望取代现有系统，成为新的基础设施标准。

放眼行业全局，我们也观察到以下几个值得关注的显著趋势。

趋势一：事务与分析范式的持续融合

从早期 TP、AP 分离，到 HTAP 的融合探索，再到今天向量检索、混合搜索等 AI 能力的全面引入，多模态数据的处理变得更加便捷。

在与众多企业 CIO、CTO 的交流中，我们听到最多的痛点是数据孤岛：数据分散于各异构系统之间，一旦需要跨系统融合分析，应用层的开发复杂度便急剧攀升。他们真正渴望的，是一套能够将交易处理、分析计算、向量检索与智能推理融为一体的统一系统。

趋势二：模型能力与数据库的融合

几乎所有主流数据库厂商都在积极探索将模型能力纳入产品体系，其中搜索与模型的结合尤为引人关注。MongoDB、Elasticsearch 等国际头部厂商已相继通过收购或自研的方式加速推进数据与 AI 的深度整合。

目前来看，这种融合尚处于相对早期的阶段，更多体现为易用性的提升；但方向已然清晰——一旦实现真正的深度融合，有望大幅压缩 AI 应用的落地成本，释放出可观的商业价值。

趋势三：AI 正加速渗透企业生产场景

2024 年初，AI 的应用基本停留在对话与问答层面，难以真正融入企业核心业务。而到 2025 年，一个标志性的转变正在发生——AI 借助 Coding 能力，以代码作为企业场景的接口，开始切入真实的生产环境。

在 RAG 构建、Agent 开发乃至“一句话生成应用”等场景中，AI 已实现初步落地。一些互联网企业走在前列，阿里、蚂蚁等均已展开大规模实践；美的等传统制造企业也在积极引入大模型，以自然语言驱动轻量级应用的快速交付。轻量级应用的落地已成现实，重量级核心应用的全面普及，或许还需一到两年的时间窗口。

那么，数据库在大模型企业应用中究竟扮演什么角色？

我认为，核心在于解决大模型的两大先天局限：解决大模型缺乏私有数据和缺乏实时记忆的问题。

第一，上下文管理：面向 Agent 的多模混合搜索

由于模型的上下文窗口有限，它需要依赖外部系统进行上下文的动态管理——无论是通过 Skill 调用还是数据直接供给。随着大模型在企业中的广泛应用，每个用户积累的记忆本身就是多模态的，这些数据需要被有效组织与检索，并实时供给 Agent 使用。

这对数据库提出了全新的要求，我将其概括为“面向 Agent 的多模混合搜索”。

传统数据库在设计之初，并未将多模态能力视为一等公民。它虽然支持 JSON、XML 等格式，但本质上是在系统成型之后的附加叠加，而非内生设计。我们的思路截然不同——在一开始设计时，把多模态能力直接设计进引擎里面。

第二，统一检索：打破数据形态的壁垒

在此基础上，我们得以实现结构化、半结构化与非结构化数据的统一搜索与融合分析，从根本上消除不同数据形态之间的处理割裂。

第三，弹性架构：为万亿级 Agent 而生

这或许是最具前瞻性的一点。我们判断，未来 Agent 的数量将达到万亿级规模，这要求底层系统具备极致的分布式弹性能力。

Agent 的流量模式高度类似“网红生态”——大多数时候静默无流量，一旦某款 AI 应用爆发，访问量可能在瞬间呈数量级增长，每个 Agent 都可能经历属于自己的“双十一”。传统的固态架构难以承载这种极端弹性，底层系统必须从架构层面完成升级。

我们认为，未来的数据库必须将上述能力有机融合为一个整体，而非堆砌成多个独立系统。

原因很简单：企业在真正落地时，最不希望看到的就是维护多套异构系统的复杂性。他们真正需要的，是一套能够从根本上打通数据孤岛的一体化方案。这也是每一位企业技术负责人面对 AI 转型命题时的第一反应——不是先选模型、先调算法，而是先把数据汇聚起来、打通。

不是叠加功能，而是重构底层：OceanBase 的 AI 原生之路

我们是如何应对这些挑战的呢？

第一，重新定义 AI 混合搜索

最初，市场普遍将“AI 数据库”等同于“向量数据库”，但这一认知很快被证明不靠谱。RAG 技术的应用场景真实存在，问题在于它的定义与实现方式绑定得过于僵化——传统 RAG 默认以向量搜索作为混合增强的唯一手段，这本身就是一种误读。

真正高质量的混合搜索增强，实现路径远不止于此。上下文管理可以基于向量、图、关系型数据、JSON，甚至可以直接调用模型本身来完成。以 OpenClaw （“龙虾”）为例，随着用户记忆不断积累、日趋复杂，我们必须对记忆进行压缩处理——而这一压缩过程本身，正是通过融合模型能力、管理上下文来实现的。

因此，真正的上下文管理，必然是多种搜索方式与模型能力的有机融合，而非对向量搜索的单一依赖。 向量搜索只是初级阶段，终点是将多模搜索能力与模型智能深度整合为一体。

第二，以 Serverless 能力支撑 Agent 架构

过去我们谈分布式，强调的是“无限扩大”——机器越多越好，往千台、万台扩展。但在 Agent 时代，分布式能力必须同时支持“无限缩小”。

Agent 的流量模式极为特殊：流量峰值时需要无限扩大，瞬间扩容应对爆发式访问，静默时则可能归零，如此反复。这就催生了一种关键能力——Scale to Zero：当访问量降至零时，系统仅需保留存储，释放全部计算资源，而存储本身的成本极低。

我们最新的架构方案，正是基于云上对象存储构建。对象存储成本低廉，但性能存在明显短板，因此需要在其上设计高效的缓存层，以精良的系统工程弥补性能差距，真正满足 Agent 的实时访问需求。当部分 Agent 流量骤然爆发时，架构需要支持在线弹性伸缩——这与传统云计算的弹性能力有所相似，但难度更高：既要能极速扩张，也要能优雅收缩。

第三，推动数据与模型的深度融合

我们认为，数据与模型终将走向深度融合。典型场景如龙虾会定期调用模型对用户记忆进行总结压缩；在搜索引擎中引入模型对数据进行深度处理，以获得更高质量的输出结果。

我们希望为用户提供的体验是——将非结构化数据直接存入数据库，无论是调用模型还是调用搜索能力，数据库均可自动完成全链路处理，整个过程对用户完全透明。

为此，我们专门推出了一款面向 AI 时代的产品——OceanBase seekdb，一个 AI 原生混合搜索数据库。

这款产品最大的优势在于轻量化。仅需一台普通笔记本、1 至 2 GB 内存即可运行，非常适合个人开发者、高校老师及研究人员使用。

由于采用单机架构，产品功能简洁清晰，无论是二次开发、功能改造还是科研实验，上手门槛都相对较低。目前所有代码均已开源，可访问seekdb.ai免费下载使用。

接下来，我将介绍 OceanBase 一体化多模数据库的技术方案。

我们的核心目标是在同一套数据库系统中，支撑交易、分析与 AI 三类工作负载场景。

在底层存储架构上，我们同时支持行存与列存——行存用于交易处理，列存服务于复杂分析。在此基础上，我们进一步原生支持向量存储格式。这些能力并非后期叠加，而是在存储引擎设计之初，就把向量和混合搜索能力内置。只有在同一套引擎内统一实现，才能将性能与成本真正做到最优。

在存储层之上，我们构建了一个统一查询优化器，支持不同的数据类型和工作负载。传统优化器的设计逻辑仅围绕结构化数据展开，但现在需要同时处理 JSON、向量、全文搜索等多种数据类型。我们将非结构化数据的处理代价全面纳入优化器的决策模型，使优化器具备跨数据类型的全局优化能力。这是单一系统架构的天然优势，如果拆分成多个独立系统来做，效果一定无法达到最优。

与传统数据库相比，我们的本质区别在于——将 AI 原生能力直接融入存储引擎与底层实现，而非在现有系统之上堆叠功能模块。与专门的向量数据库或全文搜索引擎相比，我们具备更强大的结构化数据处理能力。

更重要的是，我们相信：单纯依赖向量搜索或全文检索，远不足以解决 AI 时代的上下文管理问题。 真正的解决方案，必须是多种能力的深度融合与协同。

我们的思考分为两个层面：数据库层面，需要面向 Agent 进行重新设计——不仅要具备多模态数据的处理能力，还要能够支撑海量 Agent 的高并发访问；数据仓库层面同样如此，传统数据仓库以人工分析为主，而 Agent 驱动的分析模式与之存在本质差异。

具体体现在三个维度：

其一，Agent 的并发规模远超人工；其次，Agent 对数据实时性有更严格的要求；其三，Agent 在执行任务过程中会产生大量的探索性尝试，这要求数据库具备传统上只在文件系统中才有的能力——分支能力（Branch）。

在人工分析场景下，操作结果非对即错，通常无需额外的状态保护机制；而 Agent 的工作模式截然不同——它需要在操作前建立快照，执行完成后再根据结果决定提交或回滚。这种试错式的推理机制，要求数据库在引擎层面原生支持实时处理、快照与分支等对 Agent 友好的核心能力，而且，这些能力必须在数据库引擎内部实现。

为什么这些能力必须在引擎层原生实现，而不能外置？原因在于，一旦放到数据库外部来实现，很多功能无法达成。以快照为例，如在外部实现，意味着需要对整张表进行完整拷贝——一张 1TB 的表要即时完成拷贝，在工程上是不可行的。只有在底层引擎层面原生支持快照机制，才能真正实现这一能力。

无论数据库还是数据仓库，它们都在经历这场深层变革。

基于这样的底层设计，我们在引擎层面原生支持了一系列对 Agent 友好的核心功能。在此之上，我们正在构建面向 AI 的 DataStudio，整合 Data Agent、数据服务等能力，包括智能问数、语义管理等。在实际使用中，Agent 可通过自然语言方式进行交互，系统通过语义理解自动完成推导和执行。

同时，Agent 的执行过程支持多次尝试——成功则提交，失败则回滚，系统会保留多版本数据。这种版本管理与分支机制，类似于将 GitLab 的工作方式原生集成到数据库中。这是我们对数据库与数据仓库演进方向的核心判断。

与此同时，面对海量 Agent 的并发需求，数据仓库也需要具备更高并发的处理能力。

AI 数据库全球化的思考

最后，我想重点分享我们在 AI 数据库全球化方向上的思考。

我们认为，AI 数据库对中国而言是一个难得的历史机遇。在传统的集中式数据库领域，我们起步晚，主要谈的是国产升级；分布式数据库领域，中国凭借“双十一”等高并发场景，已实现全球领先。但分布式数据库在海外使用比例不如中国，因为海外人口和场景没那么集中。

而 AI 数据库不同。首先，中美起步时间基本相当；其次，它的普适性强，中小企业也需要；再者，AI 时代的主导力量中有大量华人参与，无论在中国还是美国硅谷，华人工程师在这一领域都扮演着关键角色。

因此，我们希望基于开源，构建一个面向全球的 AI 数据库社区。目前 OceanBase 在国内开源开发者中热度很高，连续 3 年蝉联墨天轮中国数据库流行榜榜首。我们也通过数据库大赛等形式推动产学研。五年来赛事累计覆盖 500 余所高校、超 1.1 万名学生，成为数据库领域核心人才培养的重要平台。

在分享的最后，我想谈谈对 AI 时代数据库发展的几点思考。

我认为，AI 对数据库领域的影响是深远的，但这种变化的本质并非重新定义数据库的编写方式，而是驱动数据库向两个核心方向演进：面向 Agent 的架构设计，以及面向多模态数据的处理能力。

这一演进将深刻影响数据库的底层存储引擎、SQL 执行引擎，以及公有云环境下的部署与运营方式。准确来说，这是一次对数据库底层架构的系统性重构，而非从零构建一个全新的数据库。

---

立即试用 OceanBase 企业版，体验国产数据库能力

180 天免费试用，零门槛开通