Supabase 为何放弃 PG 转投 SQLite?

先回顾一下我之前写的预言, 现在以另一种形式表现出来了: DuckDB 暴露野心，日后与PG必有一战

10 月 2 日,Supabase 同一天干了两件事: 融资 1.5 亿美元,收购一家叫 Turso (Rust 重写的 SQLite 开源项目)的数据库公司。

不是并列的两条新闻, 是同一句话的两半: Supabase 在为「每个 AI agent 都要有自己的数据库」这件事,提前买好供给。

先把数字摆出来。

• 每月新增数据库 400 万个
• 每月新增用户超过 100 万
• 新建的数据库里 70% 由 AI agent 或 AI 工具创建(6 月这个数字是 60%)
• 开发者总数 13,000,000+
• 数据库发布量同比增长 600%
• 融资 $150M,新加坡主权基金 GIC 领投,Alphabet 的 CapitalG 跟投

上半年它刚融过一轮 5 亿美元。这一轮距离上一轮,四个月。

Supabase 和 Turso 原本是两个世界的东西

Supabase 做的事不复杂:把 PostgreSQL 装进一个开发者平台,数据库、用户登录、文件存储、边缘函数、实时订阅、向量搜索,注册一个账号全给你。它的 GitHub 有 111,087 颗星。

Turso 走的是完全另一条路。它用 Rust 从零重写了 SQLite —— 不是 fork,是重写 —— 然后把服务层做成完全不用本地硬盘:数据库文件和预写日志都放在 S3 对象存储里,一台机器能挂几百万个小数据库。开源协议 MIT,24,590 颗星。

两句话概括这次合并:

以前是每个项目开一个数据库,现在是每个 AI agent 开一个数据库。

以前开库要挑配置、算成本,现在应该像建一个文件那样建。

Turso 创始人格劳伯·科斯塔出任 Supabase 的「agent 服务负责人」,联合创始人佩卡·恩伯格带着团队整体加入。

先算一笔账,再谈看好

每次看到这种「用量爆炸」的故事,先做同一个除法。

每月 400 万新库。假设每一个都付费,按 Supabase Pro 的每月 25 美元算:

每月 1 亿美元,每年 12 亿美元。

而 Supabase 的年化收入,第三方机构估算大约 1.7 亿美元。

差了 7.06 倍。

反事实在第 7 倍的位置被否掉了。这说明什么?说明 agent 建的那 400 万个库里,绝大多数停在免费档,或者根本不计费。

那真实付费率是多少?用第三方的「每月净新增收入 73.6 万美元」倒推,落在 0.7% 到 1.8% 这个量级。这是推断,不是官方数字。

这个 7 倍的差值,本身就是这次交易里最有信息量的一个数字。

上图把整条链路摊开:左边是需求,中间是 agent 用 MCP server 编程式开通数据库,之后分两档供给 —— 轻层 Turso(闲置只算存储)或重层 Supabase(每个项目一台独立实例),最后都要回答同一个问题:这个库活下来了没有,怎么进生产。

图里标红的那一格是目前最大的问题: 400 万库一个月进来,没有公开的回收机制。 免费档 1 周不活动会暂停,付费档永不暂停 —— agent 建库失败之后不删除,那笔钱会一直付下去。

那这些 agent 建的库,到底值不值钱

这是唯一真正重要的问题,而官方目前没有给出任何可观测的数据。

最好的对照组是 Neon。2025 年 5 月,Databricks 用 10 亿美元收购了 Neon。官方通稿的原话是:Neon 平台上超过 80% 的数据库由 AI agent 自动创建,每五个里就有四个是代码建出来的,不是人。

但同一个数字背后还有另外半句:这类库偏向短命实验,不是生产负载。agent 为一个原型建的库,agent 扔掉之后不回来 —— 那是一笔服务成本,不是一个客户。

所以真正该盯的从来不是 70%,而是这 70% 里面活过 90 天的有多少。

Supabase 没有披露。Turso 也没披露。

Turso 的定价页倒是把答案藏在了一句话里:「空闲的数据库只按存储计费」。

这句话很重要。闲置几乎不烧钱,意味着大批被丢弃的长尾库不再是问题,而变成了一份期权 —— 只有少数几个会长成真正的应用。但目前这只是定价页的文案,不是收入的证明。

七个人看了七遍,结论惊人地一致

我让七个不同角色各自独立看了一遍这件事,打分结果:

加权 3.52 分,满分 5 分。偏正,但没到强偏正。

七个人有两点完全一致:

一,用量是真的。 400 万库/月、同比 600%、13,000,000 开发者,这些数字互相独立、可以交叉验证,不是编出来的故事。

二,所有人把同一个洞排在第一位 —— agent 建的库能活多久,没人知道。

投资人想算单位经济学,算不出来。品牌担心被反打。PM 说不出该盯什么指标。市场运营发现整条漏斗中段是黑的。七个完全不同的视角,指向同一个空白。

这可能是本次交易最值得记住的一点: 它公布了一百个使用量指标,零个留存指标。

竞争位置:那个格子原来真的空着

横轴是每个库的成本,纵轴是供给方式。

合并之前:

• Turso 独占了右下角 —— 极便宜,agent 建库不要钱。但它没有生产升级路径,也没有全套后端能力。
• Neon 在上面 —— 80% 以上由 agent 建,500 毫秒起一个实例,但贵,一个库一台机器。
• Supabase 在右上 —— 工具链齐全,但每个项目一台独立计算实例,agent 建库很贵。
• pgvector 自建 在左下 —— 免费,但要自己运维。

合并之后,右下那个格子第一次有了完整形状: 便宜的开头,完整的结尾,中间不用换工具。

但问题是,这一格的入口已经通透了,出口是断的。

出口那一端叫 Multigres —— 它的作者是 Sugu Sougoumarane,Vitess 的共同创建者,当年靠这套架构撑起了 YouTube 的 MySQL。现在他把架构移植到了 PostgreSQL 上,Apache 2.0 开源,今年 6 月发布。

但它现在是 v0.1 alpha,不是生产可用。

这是整件事最不匹配的地方: 开头已经发货并且在放量,结尾还只是一页 slide。

官方承诺了三条,其中一条现在兑现不了

Turso 在自己的博客里给了用户三条承诺:

1. Turso 继续运营
2. 开源继续开源
3. 有一条明确的升级路径

第三条原文是:「当 SQLite 不够用时,你可以经由 Supabase 生态迁到标准 Postgres,再经由 Multigres 一直到 PB 级规模。」

前两条当场可验证:协议是 MIT,收购之后 10 月 4 日仓库还有提交。

第三条 —— 终点是 v0.1 alpha。Turso 自己在做的 Postgres 前端 pgmicro 至今只是个原型,官方从未公布过生产就绪的时间表。二手估计是 12 到 18 个月,那落在 2027 年上半年。

承诺是公开的,兑现是可查的,现在查就是空的。

社区其实有办法盯的:看外部贡献者的人数,而不是看 commit 数。内部化维护是一个逐渐发生的过程,外部开发者永远是先行指标。

还有三个容易被忽略的坑

一,别把 70% 读成 70% 的收入。

70% × 400 万 = 每月 280 万个 agent 库,这个数字站得住。但如果有人据此推「70% 的收入来自 agent」,意味着 1.19 亿美元 —— 正好和前面那个 7 倍反事实直接打架。一旦被拆穿,叙事会反噬。

二,合并之后多了一个新摩擦。

如果客户既要自带云部署(只有 Turso 企业版有),又要完整合规能力(Supabase Team 599 美元起、Turso Pro 499 美元起),那就是每月 1,098 美元、两份合同。

这不是不能买。但它是这次合并新产生的问题,合并前不存在。

三,计费单位和产品哲学对不上。

官方产品哲学的原话是「agent 应当像建文件一样建数据库」。但 Supabase 的计费模型是「每个项目一台独立计算实例」。

一个文件的成本结构,不是一个虚拟机的成本结构。

Turso 那套「闲置只算存储」才是 agent 场景该有的计费单位 —— 该按对象存储计,不该按实例计。这个错配意味着大部分 agent 库要么被按虚拟机的钱计费,要么干脆躺在免费档。

顺带一个硬伤:Turso 文档里写明,SQLite 的 VACUUM 命令当前被禁用。对存储膨胀敏感的应用,这是直接的功能缺失。

怎么判断这笔交易对不对

最该盯的信号只有一个,而且它必须来自官方:

agent 建的库,30 天、90 天、180 天之后还活着的比例。

如果这个数字可观,那 Supabase 的收入曲线就从「用量故事」变成「管道故事」,这笔收购的价值立刻成立。

如果绝大多数 agent 库在 30 天内消失,那 400 万库/月就纯粹是成本中心 —— 但即便如此,结论也不是全盘否定:Turso 那套「闲置只算存储」的架构会从优势变成救命稻草,正是它让长尾废弃库不烧钱。

这次收购,技术对,可能比叙事对更可靠。

另外两件值得定期看的事:

• Claude Code 是不是还是最大单一来源。 现在它贡献了大量新库,但这一层的防御成本几乎为零 —— 换一次模型默认后端就能被替换。护城河最薄的一层,恰好是增长最快的一层。
• agent 建立的库有没有生命周期管理。 每月 400 万个库进来,目前没有任何公开的批量回收机制。免费档 1 周不活动会暂停,付费档永不暂停 —— agent 建库失败后不删除,那笔钱会一直付下去。这是最便宜的一个缺口,也是最容易随规模长大的一个。

最后

四个月,1.5 亿美元,一笔对价未披露的收购,70% 的新库由机器创建,13,000,000 个开发者在上面写代码。

这笔交易把「每个 agent 一个数据库」从一个说法,变成了一个有人认真下注的基础设施层。

但下注的证据,目前全是使用量,没有一个留存数字。

用量说明需求是真的。留存说明需求能不能变成收入。Supabase 给了前者,没给后者。

接下来 90 天,只需要盯三件事:官方是否首次公布库存活率、Turso 的 Postgres 前端是否出 beta、是否公布收入。任意一件落地,这个判断都要重估。