2025 年 2 月，Andrej Karpathy 在 X 上随手写下了"vibe coding"。

不到一年，它就成了柯林斯词典年度词汇。

同时，瑞典公司 Lovable 的 ARR 在2026年6月冲到5亿美元。平台上每周新增约100万个项目，累计超过5000万个，其中八成用户没有技术背景。

Cursor 的 ARR 则从年初约 20 亿美元增长到年中接近 40 亿美元，短短几个月完成翻倍。

这一趋势也几乎同步发生在国内。蚂蚁灵光、百度秒哒、腾讯"吐司"、字节 Trae几乎成为了大厂标配。

不过应用生成容易，数据库的服务对象也跟着变了。以前数据库服务的是像淘宝、微信这种"少量大应用，但 coding 时代，成千上万个应用都需要自己的数据空间。

而对于 AI 生成应用来说，数据空间并不只是存储空间，更是一份支撑应用持续运行的“记忆”。它需要保存应用的数据结构、业务状态，并保证后续能够被准确调用和计算。

面对“海量 AI 生成应用×动态 Schema ”，这也对数据基础设施提出新的挑战，本文将尝试从实际应用出发，结合蚂蚁 OceanBase 的实践，拆解这一问题以及背后的其解决思路。

01

为什么传统数据库方案开始失效？

这股生成热潮最终会给数据库带来多大压力？先来看一组数据。

根据 Sensor Tower 的数据来看，2026年苹果商店的上半年新增约56万个应用，几乎相当于2025年全年总量。

全年有望突破100万（此前纪录为2016年的89万）。明确归因于 vibe coding 工具（Replit、Bolt.new 等）带来的非专业开发者提交激增。

这意味数据库面对的不再是"一个越来越大的数据库"，而是数千万个彼此独立的数据空间。

以蚂蚁灵光为例，上线四个月便累计生成了超过 3000 万个闪应用。

与传统互联网应用不同，这些 AI 生成应用有着鲜明的新特征：数量巨大、单体数据量小、Schema（表结构）动态生成，绝大多数应用被"搓"出来玩几次就归于沉寂，但用户哪天重新点开，又必须立刻响应。

一位接近项目的技术人士总结过这种负载的诡异之处——传统的数据库规模问题，问的是"一个库能装多少数据"；而这里的问题是"一套数据库能不能同时容纳3000万个互不相同的'小库'"。

有人或许会认为，既然 AI 能够生成代码，数据计算是不是也可以交给大模型完成？

现实并非如此。AI 擅长生成页面、代码甚至业务流程，但涉及金额汇总、排序、过滤等需要绝对准确结果的计算，仍然需要数据库完成。

以一个典型的记账闪应用为例：用户不仅要记下每笔收支，还要能"按月汇总支出"。而做这类精确计算的，不能是大模型——写诗、总结它擅长，但让它保证每一分钱都对得上，目前还做不到；也不可能是平台——没有任何团队能为3000万个结构各异的应用挨个开发计算接口。

从 Agent 视角看，这些能力共同构成了应用的“运行记忆”：Schema 定义应用如何理解数据，业务数据记录应用与用户交互形成的状态，应用标识划定记忆边界，SQL 负责对这些状态进行准确调用和计算。

因此，灵光面对的不只是海量应用的数据存储问题，而是海量独立运行记忆的管理问题：每份记忆都很小，但数量极多；结构各不相同，却必须彼此隔离，并能够持续查询和更新。

所以每个闪应用都需要一套货真价实的数据库能力：定义自己的表结构、读写数据、执行 SQL 查询。生成只要30秒，数据库的承诺却要是永久的。

因此，数据库依然承担着持久化存储和确定性计算的职责。

只是过去数据库的两种典型方案，在 AI 生成应用场景下都开始失效。

第一条路，是所有应用共享一张 JSON 大表。它的优势是物理表数量少，但代价同样明显，数据库原本擅长的 SQL 聚合、过滤、排序等能力难以直接使用，很多计算只能重新回到业务层实现，多租户场景下的数据权限隔离也变得更加复杂。这条路等于只解决了"存"，放弃了"算"。

第二条路，为每个应用单独创建一张物理表。体验是完整的，但规模是灾难性的：每创建一个应用就要对数据库控制面发起一次 DDL 操作，3000万次创建意味着控制面持续承压；而这些应用大多数据量极小，开销远超业务数据本身。就像为一个只住了两天的客人盖一栋楼，楼越来越多，住的人没几个。

蚂蚁集团平台技术事业群总架构师黄挺曾如此形容："不能让每个人都单独盖一栋房子，也不能让所有人睡一个大通铺。"

要知道数据库行业过去几十年的优化方向，无论是单机性能还是分布式扩展，瞄准的都是"少量、稳定、巨型"的库表；而 AI 时代的负载第一次呈现出"海量、动态、长尾"的形态。

所以 AI 时代真正需要的，是一条介于两者之间的新路径。

02

OceanBase：

每人一间办公室，共享一栋楼

既然"独立"和"共享"无法二选一，那么 OceanBase 则是在两者之间找到一条新的路径：将应用的数据模型与底层物理存储解耦：每个应用保持独立的数据模型和访问边界，底层则共享存储和计算资源。

OceanBase 产品部总经理韩富晟把这个方案比作一栋写字楼："每家公司都有自己独立的办公室，按自己的风格装修、存放文件，但整栋楼共享水电和物业。

放到数据库里，对应的是一种新的设计思路：逻辑独立，物理共享。每一个 AI 应用看到的，仍然是一张属于自己的数据表；而在底层，它们共享的是同一套物理存储资源。开发者不需要感知底层如何组织数据，依旧按照熟悉的方式定义 Schema、编写 SQL，但数据库内部已经换了一种组织方式。

为了做到这一点，OceanBase 首先把"表"拆成了两层。

一层负责记录每个应用的数据结构，也就是 Schema；另一层负责保存真正的数据内容。所有应用的数据最终都会写入共享的数据表中，并以 JSON 形式存储，而各自的表结构则单独维护。

无论平台新增多少应用，物理表的数量都不会再随着应用数量线性增长。

不过把数据统一存成 JSON，只解决了一半的问题。

如果数据库只能存，不能算，那么开发者最终还是需要把数据取出来，在业务层重新完成聚合、过滤、排序等计算，这恰恰又回到了第一部分提到的那条"共享 JSON 大表"老路。

因此，OceanBase 又增加了一层"翻译"能力。

可以把它理解成一位同声传译。开发者依然编写标准 SQL，不需要关心底层数据是否以 JSON 形式保存；数据库会通过 JSON Table SDK 将这些 SQL 自动转换成对共享存储的访问方式，再利用 JSON_TABLE() 将 JSON 数据映射成关系表，继续完成聚合、过滤、统计等计算。

对于开发者来说，数据库的使用方式几乎没有变化；变化发生在数据库内部。

共享资源之后，另一个必须回答的问题是隔离。

3000万个应用共享一套存储，如何防止 SQL 越界串门？方案是，在 SQL 执行过程中，每条语句都会自动附带应用标识等限制条件，并结合白名单机制约束可执行范围。开发者看到的是一张属于自己的逻辑表，数据库真正执行时，则会自动完成访问边界的控制。

这种设计还带来了另一个好处。

绝大多数 AI 生成应用生命周期短、访问量低，共享资源能够显著降低运行成本；而当某个应用逐渐成长为高频业务时，又可以平滑迁移到独立物理表，而无需重新设计数据结构。

从技术实现来看，这套方案重新定义数据库组织海量 AI 应用数据的方法：逻辑上保持独立，物理上尽可能共享；计算仍然留在数据库完成，而不是重新回到业务层。

这也是 OceanBase 希望解决的核心问题——AI 数据平台如何以可控成本，承载数千万个持续增长的数据空间。

03

数据库成为 AI 应用的"基础设施"

据彭博社援引知情人士报道，外界曾将 OceanBase 看作中国的 Databricks 。

两家公司虽然起点不同——前者从分布式数据库内核出发，后者从数据分析和 AI 平台起步。但最终都在回答同一个问题：AI 应用大规模涌现之后，数据基础设施应该如何演进。

OceanBase 在灵光项目中的实践，给出的并不是某一项技术，而是一种新的数据组织思路：物理资源共享、逻辑边界独立、确定性计算留在数据库。

将灵光的案例放在更大的坐标系里看，它重新定义了数据库的"规模"。互联网时代，人们讨论数据库，关注的是单库容量、事务处理能力和性能；AI 时代，新的挑战变成了如何以有限资源承载千万级动态数据空间，同时兼顾数据隔离、确定性计算和资源成本。

同时数据库承担的角色也开始发生变化。

过去，它主要回答"数据怎么存、怎么算"；如今，随着越来越多应用和数据访问由 Agent 自动完成，它还需要回答" AI 如何持续、安全地使用数据"，以及如何组织资源、服务开发者和 Agent。

当应用生成成本不断趋近于零，竞争开始从"如何生成应用"转向"如何承载应用"。

对于 AI 应用开发者而言，模型决定了应用能做什么，而数据基础设施则决定了应用能否真正跑起来、跑得稳。这或许也是灵光案例最大的启发：AI改变了软件开发，也重新定义了数据库。

韩富晟表示说，“ OceanBase 会持续探索，搭建面向 Agent 的数据底座，为下一代 AI 应用构建真正可依赖的数据基础设施。”

3000万个闪应用只是这场探索的第一站，当创建应用的门槛趋近于零，数据层的竞争才真正开始。

（转载自：AI科技评论）