Supabase 再拿 1.5 亿美元并收购 Turso：70% 的新数据库是 AI agent 建的
10 月 2 日，Supabase 宣布两件事一起发：1.5 亿美元新融资，以及收购 Turso。领投方是新加坡主权基金 GIC，跟投的有 Alphabet 旗下的 CapitalG、IronArc、SquarePeg。
增长数字全在”agent 建的库”上
官方公告里的几个数：
- 每月新增用户超过 100 万，新增数据库 400 万个
- 70% 的新数据库由 agent 或 AI 驱动工具创建
- 6 月时公布的是数据库同比增 600%，当时 agent 已经贡献了多数新增库
- 平台开发者超过 1300 万
- 距离上一轮 5 亿美元 Series F 只过了 4 个月
这轮估值 106.5 亿美元，而 6 月那轮是 105 亿——涨了不到 2%。有报道指出 9 月递交的 SEC Form D 显示这更像是同一轮的扩展，而不是新一轮的重新定价，部分资金用于给员工提供流动性。
为什么要买 Turso
这是个技术决定，逻辑值得记一下。
Supabase 的主体是 Postgres，一个项目一个独立数据库。但 agent 要的不是这个：它会为了跑一次原型随手建一个库，用完就扔。这类需求要的是毫秒级创建、空闲时几乎零成本、不需要单独开机器。
Turso 把 SQLite 用 Rust 重写，去掉单写入者限制，云端采用无盘架构，预写日志放对象存储。结果是一台服务器能托管数百万个小库，用的时候加载、闲下来挂起。
Turso 创始人 Glauber Costa 加入 Supabase 任 agentic services 负责人，联合创始人 Pekka Enberg 和整个团队一并过去。Turso 平台继续独立运营，数据库保持开源。
已知在用的客户：Superhuman、Sauna.ai、CTO.new、Mastra。
对做产品的人意味着什么
- 每个 agent 一个库正在成为标准做法。 不是共享 schema，是各给一个独立存储。隔离的好处很直接：一个跑飞了的 agent 能碰到的范围被限制在它自己的库里。
- 空闲成本决定了你能不能允许”随手建库”。 如果你按小时为每个库付费，你就不敢让 agent 随便建库，于是 agent 的能力被成本锁住。这是选后端时该问的第一个问题，不是 QPS。
- Turso 存在的理由就是”丢弃的库不该花钱”。 一个 agent 建的库九成不会变成产品。如果闲置库几乎零成本，那九成就是可接受的损耗。
泼冷水
第一，Supabase 这轮和上一轮都没有公布收入数字。106.5 亿的估值完全建立在用量指标上：数据库创建量、开发者数、agent 占比。用量不等于收入——agent 建的库大量是短命实验，一个被丢弃的库是成本，不是客户。
第二，增长的集中度是个风险。6 月的报道里提到，Claude Code 是平台上新增数据库的最大单一来源。也就是说，很大一块增长挂在一个外部产品上，那个产品改一下行为，数字就会变。
第三，Turso 的收购价格没有公布。公告说”继续独立运营”，这种表述在收购语境里通常意味着整合会很慢，短期内你得不到什么新东西。
具体建议
- 如果你的 agent 需要临时存储，优先选”按库计费、空闲免费或近零”的方案，而不是按机器计费。
- 给每个 agent 单独开库，不要共用一个 schema 靠字段区分。隔离是安全边界，不是性能优化。
- 迁移路径提前想好。Turso 这边保持 SQLite，Supabase 主体是 Postgres，两边不通用。现在选哪边走，以后换过去要重写。