Vibe Coding正在重写软件开发，也正在重构数据库

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



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

既然



"



独立



"



和



"



共享



"



无法二选一，那么



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



数据平台如何以可控成本，承载数千万个持续增长的数据空间。

据彭博社援引知情人士报道，外界曾将



OceanBase



看作中国的



Databricks



。

两家公司虽然起点不同



——



前者从分布式数据库内核出发，后者从数据分析和



AI



平台起步。但最终都在回答同一个问题：



AI



应用大规模涌现之后，数据基础设施应该如何演进。

OceanBase



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

将灵光的案例放在更大的坐标系里看，它重新定义了数据库的



"



规模



"



。互联网时代，人们讨论数据库，关注的是单库容量、事务处理能力和性能；



AI



时代，新的挑战变成了如何以有限资源承载千万级动态数据空间，同时兼顾数据隔离、确定性计算和资源成本。

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

过去，它主要回答



"



数据怎么存、怎么算



"



；如今，随着越来越多应用和数据访问由



Agent



自动完成，它还需要回答



" AI



如何持续、安全地使用数据



"



，以及如何组织资源、服务开发者和



Agent



。

当应用生成成本不断趋近于零，竞争开始从



"



如何生成应用



"



转向



"



如何承载应用



"



。

对于



AI



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



AI



改变了软件开发，也重新定义了数据库。

韩富晟表示说，



“ OceanBase



会持续探索，搭建面向



Agent



的数据底座，为下一代



AI



应用构建真正可依赖的数据基础设施。



”

3000



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

（转载自：AI科技评论）