作者丨成妍菁
编辑丨胡敏
2025 年 2 月，Andrej Karpathy 在 X 平台提出"vibe coding"概念。不到一年，该词入选柯林斯词典年度词汇。与此同时，瑞典公司 Lovable 的 ARR 于 2026 年 6 月突破 5 亿美元，平台累计项目超 5000 万个，其中八成用户无技术背景；Cursor 的 ARR 也在数月内从 20 亿美元翻倍至 40 亿美元。
国内大厂迅速跟进，蚂蚁灵光、百度秒哒、腾讯“吐司”及字节 Trae 等应用生成工具成为标配。然而，应用生成的低门槛引发了数据服务模式的剧变：数据库的服务对象从“少量巨型应用”转向“海量独立应用”。对于 AI 生成应用而言，数据空间不仅是存储容器，更是支撑其持续运行的“记忆”，需精确保存数据结构与业务状态。
面对“海量 AI 生成应用×动态 Schema"的挑战，传统数据基础设施亟待升级。本文将结合蚂蚁 OceanBase 的实践，拆解这一难题及其解决思路。
01 为什么传统数据库方案开始失效？
生成式 AI 热潮给数据库带来了前所未有的压力。Sensor Tower 数据显示，2026 年上半年苹果商店新增应用约 56 万个，接近 2025 年全年总量，全年有望突破 100 万大关。这主要归因于 Replit、Bolt.new 等 vibe coding 工具带来的非专业开发者激增。
这意味着数据库不再仅面对“一个越来越大的库”，而是数千万个彼此独立的数据空间。以蚂蚁灵光为例，上线四个月累计生成超 3000 万个闪应用。这些 AI 生成应用具有数量巨大、单体数据量小、Schema 动态生成等特征，且多数生命周期短暂，但需随时响应唤醒。
传统数据库关注“单库容量”，而新场景要求“一套系统容纳数千万个异构小库”。尽管 AI 擅长生成代码，但在金额汇总、排序过滤等需要绝对准确性的计算上，仍必须依赖数据库。以大模型直接处理确定性计算目前并不可行，平台也无法为千万级异构应用逐一开发接口。
从 Agent 视角看，Schema 定义数据理解方式，业务数据记录交互状态，SQL 负责准确调用与计算，共同构成应用的“运行记忆”。因此，每个闪应用都需要完整的数据库能力：定义表结构、读写数据、执行 SQL。生成仅需 30 秒，但数据承诺必须是永久的。
过往两种典型方案在此场景下均显乏力：
一是所有应用共享一张 JSON 大表。虽减少了物理表数量，但牺牲了 SQL 聚合、过滤等核心能力，迫使计算回流至业务层，且多租户隔离复杂，可谓“只解决了存，放弃了算”。
二是为每个应用创建独立物理表。虽体验完整，但规模灾难明显：3000 万次 DDL 操作将压垮控制面，且对于数据量极小的应用，资源开销远超业务价值，如同“为住两天的客人盖一栋楼”。
正如蚂蚁集团平台技术事业群总架构师黄挺所言：“不能让每个人都单独盖一栋房子，也不能让所有人睡一个大通铺。”AI 时代的负载呈现“海量、动态、长尾”形态，亟需一条介于两者之间的新路径。
02 OceanBase：每人一间办公室，共享一栋楼
针对“独立”与“共享”的矛盾，OceanBase 提出了“逻辑独立，物理共享”的新路径：将应用的数据模型与底层物理存储解耦。每个应用保持独立的数据模型和访问边界，底层则共享存储和计算资源。
OceanBase 产品部总经理韩富晟将此比作写字楼模式：“每家公司拥有独立办公室，按自身风格装修存放文件，但整栋楼共享水电物业。”
在具体实现上，OceanBase 将“表”拆分为两层：一层记录各应用的 Schema 结构，另一层存储实际数据内容。所有应用数据最终写入共享数据表并以 JSON 形式存储，而各自的表结构单独维护。这使得物理表数量不再随应用数量线性增长。
为解决 JSON 存储带来的计算难题，OceanBase 引入了“翻译”机制。开发者依然编写标准 SQL，数据库通过 JSON Table SDK 自动将其转换为对共享存储的访问指令，利用 JSON_TABLE() 函数将 JSON 数据映射为关系表，从而在底层完成聚合、过滤等复杂计算。对开发者而言，使用习惯无需改变，变化发生在数据库内部。
在资源共享的同时，隔离性至关重要。针对 3000 万个应用共享存储的场景，OceanBase 在 SQL 执行过程中自动附带应用标识等限制条件，并结合白名单机制约束执行范围，确保数据互不串扰。
该设计还具备弹性优势：绝大多数短生命周期、低访问量的 AI 应用可低成本共享资源；当某应用成长为高频业务时，可平滑迁移至独立物理表，无需重构数据结构。
这套方案重新定义了海量 AI 应用数据的组织方式：逻辑独立、物理共享、计算留库。其核心目标是让 AI 数据平台以可控成本，承载数千万个持续增长的数据空间。
03 数据库成为 AI 应用的“基础设施”
外界曾将 OceanBase 誉为中国的 Databricks。两者虽起点不同——前者源于分布式数据库内核，后者始于数据分析与 AI 平台，但最终都指向同一命题：AI 应用大规模涌现后，数据基础设施应如何演进。
OceanBase 在灵光项目中的实践，提供了一种新的数据组织范式：物理资源共享、逻辑边界独立、确定性计算留在数据库。这不仅重新定义了数据库的“规模”维度——从关注单库容量转向如何以有限资源承载千万级动态数据空间，也改变了数据库的角色定位。
过去，数据库主要解决“数据怎么存、怎么算”；如今，随着 Agent 自动完成更多应用构建与数据访问，数据库还需回答"AI 如何持续、安全地使用数据”，以及如何高效组织资源服务开发者与 Agent。
当应用生成成本趋近于零，竞争焦点已从“如何生成”转向“如何承载”。对 AI 开发者而言，模型决定应用能做什么，而数据基础设施决定应用能否跑稳、跑远。AI 不仅改变了软件开发，也重新定义了数据库。
韩富晟表示："OceanBase 将持续探索，搭建面向 Agent 的数据底座，为下一代 AI 应用构建真正可依赖的数据基础设施。”3000 万个闪应用仅是起点，当创建门槛消失，数据层的竞争才刚刚拉开帷幕。
未经「AI 科技评论」授权，严禁以任何方式在网页、论坛、社区进行转载！
公众号转载请先在「AI 科技评论」后台留言取得授权，转载时需标注来源并插入本公众号名片。