首页 / 资讯详情
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秒，数据库的承诺却要是永久的。因此，数据库