Vibe Coding 重写软件开发，也重构数据库：OceanBase 如何承载千万级 AI 应用数据空间

事件概述

2025 年 2 月，Andrej Karpathy 提出“vibe coding”，不到一年便成为柯林斯词典年度词汇。AI 生成应用随之爆发：海外方面，Lovable 的 ARR 在 2026 年 6 月达到约 5 亿美元，平台每周新增约 100 万个项目、累计超过 5000 万个，其中约八成用户没有技术背景；Cursor 的 ARR 从年初约 20 亿美元增长到年中接近 40 亿美元。国内方面，蚂蚁灵光、百度秒哒、腾讯“吐司”、字节 Trae 等也成为大厂标配。

核心信息

• 应用爆发带来全新数据库负载：Sensor Tower 数据显示，2026 年上半年苹果 App Store 新增约 56 万个应用，几乎相当于 2025 年全年总量，全年有望突破 100 万（此前最高纪录为 2016 年的 89 万），其中明确归因于 Replit、Bolt.new 等 vibe coding 工具带来的非专业开发者提交激增。蚂蚁灵光上线四个月便累计生成超过 3000 万个闪应用。

• AI 应用的数据空间是一种“运行记忆”：每个 AI 应用都需要独立的 Schema、业务状态、应用标识和 SQL 计算能力。AI 适合生成页面、代码和流程，但金额汇总、排序、过滤等需要绝对准确结果的计算，仍必须由数据库完成。每个闪应用都需要“定义表结构、读写数据、执行 SQL”的完整数据库能力；生成一个应用只需 30 秒，数据库却要长期支撑其运行。

• 传统数据库方案开始失效：共享一张 JSON 大表虽然物理表数量少，但 SQL 聚合、过滤、排序能力难以直接使用，计算被迫回到业务层，多租户权限隔离也更复杂；为每个应用单独建物理表体验完整，但 3000 万个应用意味着 3000 万次 DDL 操作，控制面持续承压，而绝大多数应用数据量极小，资源开销远超实际数据。

• OceanBase 的路径：逻辑独立、物理共享：将应用的数据模型与底层物理存储解耦，把“表”拆成 Schema 层和数据层。所有应用的数据以 JSON 形式写入共享物理表，各自的表结构单独维护，物理表数量不再随应用数量线性增长。开发者仍编写标准 SQL，数据库通过 JSON Table SDK 和 JSON_TABLE() 将 SQL 自动转换到共享存储，并继续完成聚合、过滤、统计等计算。

• 隔离与成本控制：SQL 执行时自动附带应用标识，并结合白名单机制限制访问范围，防止 3000 万个应用互相越界。绝大多数 AI 生成应用生命周期短、访问量低，共享资源可显著降低成本；某应用成长为高频业务后，可平滑迁移到独立物理表，无需重新设计数据结构。

值得关注

数据库的“规模”定义正在改变：过去关注单库容量、事务能力和性能，现在则要看能否以有限资源承载上千万个动态数据空间，并兼顾数据隔离、确定性计算和成本。据彭博社援引知情人士，OceanBase 曾被外界看作“中国的 Databricks”；两者起点不同，但都在回答同一个问题：AI 应用大规模涌现后，数据基础设施应如何演进。

当应用生成成本趋近于零，竞争重点从“如何生成应用”转向“如何承载应用”。模型决定应用能做什么，数据基础设施决定应用能否稳定运行。3000 万个闪应用只是开端，数据层竞争才刚刚开始。