蚂蚁灵光平台已承载约3000万个闪应用，每个应用都需要独立的数据能力。OceanBase 首次公开其支撑方案——通过逻辑表实现"应用数据模型独立、底层物理存储共享"，在"独立"与"共享"之间找到了架构级平衡。
3000万个闪应用，每个都需要独立的数据能力——数据往哪儿放？
蚂蚁灵光是一款面向大众的AI应用生成产品，用户说一句话就能生成一个"闪应用"——记账本、报名页面、打卡工具，30秒就能"手搓"出来。上线仅几个月，平台累计诞生的闪应用已超过3000万个。
应用生成容易，但数据往哪儿放？每个能持续运行的应用都需要自己的数据能力。比如一个记账应用，用户不仅要记下每笔收支，还要能按月汇总支出。这种精确计算不是大模型的强项——写诗、总结它擅长，但让它保证每一分钱都对得上，目前还做不到。平台也不可能为每个应用单独写一套后端逻辑。
灵光团队尝试过两条路，但都走不通：
把所有用户数据打包成JSON塞进一张大表。表是省了，但数据库的求和、排序等计算能力用不上了——想汇总支出，得先把数据全捞出来在业务代码里自己算，效率极低，多用户权限也很难控制。
为每个闪应用单独建一张物理表。每次创建都要操作数据库控制面，压力极大；大多数应用数据量很小，但表的数量却极其庞大，对存储本身也造成了很大负担——地不够用。
"这就像一栋楼里住了3000万人，不能要求每个人单独盖一栋房子，地不够用；但也不能让所有人都睡一个大通铺，没法过日子。"
——蚂蚁集团平台技术事业群总架构师 黄挺
答案是：每人一个房间，共享一栋楼。
OceanBase 给灵光设计的方案是面向海量AI应用的逻辑表——每个闪应用在操作层面仍然拥有独立的表结构，可以建表、插入数据、执行SQL查询，和使用独立数据库的体验完全一样。但底层，这3000万个逻辑表共享同一套物理存储，数据库不再为每个应用单独创建物理表。
具体工作流程：
OceanBase产品部总经理韩富晟把这个方案比作一栋写字楼："每家公司都有自己独立的办公室，按自己的风格装修、存放文件，但整栋楼共享水电和物业。每个公司的独立性和隐私都有保障，整栋楼的建造成本也远低于让每家公司自己盖一栋楼。"
如果某个闪应用的用户量真的变得非常大，还可以将其一键迁移到独立的物理表上，获得更高的性能——独立与共享，不再是非此即彼的选择。
一个具体的场景，比任何理论都更有说服力。
类似的场景还有报名页面、打卡工具、问卷收集……每一个闪应用都拥有自己的"独立房间"，但整栋"写字楼"的运营成本远低于让每个应用独占一套基础设施。
但技术方案只是故事的一部分。能支撑3000万应用共享一套数据库，背后是十六年的积累。
OceanBase 从分布式数据库起步，经历了从支撑蚂蚁集团核心交易系统，到服务交通银行、中国移动等数千家企业的过程。蝉联中国分布式数据库本地部署市场份额第一，用十六年时间证明了其在金融级核心场景中的可靠性。
灵光的实践印证了一个更大的行业趋势：过去三年，大模型的智力在快速提升，但企业真正把AI用起来，卡点往往不在模型本身，而在于数据——AI能不能触达准确、完整的企业数据，决定了它到底是"玩具"还是"工具"。
这正是OceanBase从"分布式数据库"走向"AI数据平台"的战略方向。今年6月，OceanBase发布了新一代湖库一体的AI数据库，将结构化数据、非结构化数据和向量数据统一到同一套引擎中管理，让AI Agent能够一次获取完整的业务上下文。目前这一能力已在蚂蚁阿福、灵光等核心场景完成验证，并在数十家企业客户中测试。
"OceanBase会持续探索，搭建面向Agent的数据底座，为下一代AI应用构建真正可依赖的数据基础设施。"
——OceanBase产品部总经理 韩富晟
当AI应用数量从3000万增长到3亿，数据架构的"独立性vs共享性"矛盾会更加突出。逻辑表方案不是万能药，但它提供了一条可行路径——不是让每个应用独占资源，也不是让所有应用混用同一空间，而是在架构层面实现"独立体验+共享成本"。这背后反映了一个趋势：数据基础设施的竞争，正在从"能存多少"转向"能支撑多少AI应用"。
目前，逻辑表方案已在蚂蚁灵光平台全面应用，支撑着3000万个闪应用的数据运行。这套架构为AI时代的海量应用数据管理提供了一个可参考的范式——当每一行代码都能生成一个应用，数据基础设施必须学会"以一当万"。