Supabase 收购 Turso：智能体需要为每个任务配备数据库
Supabase 于 10 月 2 日宣布，它筹集了 1.5 亿美元，并将收购基于 SQLite 的数据库公司 Turso。本轮融资由新加坡的 GIC 领投，Alphabet 的增长基金 CapitalG、IronArc 和 SquarePeg 参投。收购价格未披露，融资公告不应被解读为收购价格。
这笔交易背后的架构赌注才是有趣的部分。Supabase 围绕 Postgres 建立了自己的业务，Postgres 是一种关系型系统，为共享一个一致存储的应用程序而设计。Turso 从头重写了 SQLite，去掉了其单写入者限制，然后通过一种无盘架构交付，将预写日志保存在 S3 上。结果就是，可以按需、为每个智能体配置数据库，而成本仅为为每个智能体启动一台机器的一小部分。
Supabase 引用的数字
Supabase 表示，现在每月新增超过 100 万用户和大约 400 万个数据库。它报告称，平台上约 70% 的新数据库由智能体或 AI 驱动的工具创建。今年 6 月，它报告数据库数量同比增长 600%，并表示智能体已经负责了大多数新部署。该公司称，超过 1300 万开发者使用该平台。
这些是公司报告的用户采用数据，而数据库创建量与收入或留存率并不是同一个衡量标准。智能体为某个任务启动、一小时后就被弃用的数据库，仍然会计入那个月度总数。这些数字确实显示的是需求曲线的形状：数据库创建量的增长速度超过了创建它们的人类数量，而这正是按应用程序配置数据库的模式正承受压力的信号。
为什么每个智能体一个数据库会打破旧的算术
基础设施的单元正在改变。当人类开发者构建应用程序时，一个数据库服务许多用户，配置它的成本会摊销到一个长期存在的项目中。当智能体运行一个任务时，它可能需要自己的临时存储来保存状态、记忆或中间结果，而且可能只需要用几分钟。
在传统的托管数据库模式下，为每个智能体配置一个实例，在那个规模上行不通。分配服务器、配置服务器并对其计费的开销，使其中运行的小型工作负载的价值相形见绌。Turso 的主张是，创建一个数据库的成本几乎为零，保持其空闲的成本也几乎为零，因此启动一百万个数据库是一种常规操作，而不是一次会计事件。
Supabase 为 Turso 引用的客户名单包括 Superhuman、CTO.new、Sauna.ai 和 Mastra。Turso 创始人 Glauber Costa 将加入 Supabase，担任智能体服务负责人，联合创始人 Pekka Enberg 及团队其他成员也将一同加入。
对于已经在使用 Turso 的人来说，有一个细节值得注意。该公司早期的 libSQL 分支和较新的 Rust 引擎是不同的实现，二者并不具备相同的功能集。Turso 在 2025 年 1 月的一篇重写公告中解释了这一过渡。团队在假设营销页面上列出的某项功能可用于生产环境之前，应先检查其部署运行在哪个引擎上。
这项收购针对的竞争
这次收购也澄清了 Supabase 的竞争对象。其付费产品包括身份验证、存储、边缘函数、实时订阅和向量搜索，这使它在托管后端市场中与 Firebase、MongoDB Atlas 和 AWS Aurora 竞争，而不是与单一数据库供应商竞争。
这些竞争对手在智能体层各有不同的弱点。Firebase 将开发者绑定到文档模型和 Google 的云上。MongoDB Atlas 可以灵活地建模数据，但按集群收费，而不是按智能体工作的单元收费。Aurora 功能强大，但在小规模下价格昂贵，其配置方式不适合只存在几分钟的任务。
Turso 的贡献是最小可能的存储单元。它提供并发写入、原生向量搜索和浏览器内执行，以及设备与云之间的嵌入式复制。最后一项能力对一类部分运行在用户机器上的应用程序很重要，在这类场景中，往返云端数据库对于该问题而言并不是正确的形态。
这种升级路径就是商业机制。一个以单个 SQLite 数据库起步并成长为真正应用程序的项目，会迁移到 Postgres，并随之进入付费计划。Supabase 的论点是，在智能体创建项目的那一刻就抓住它，比之后再去获取开发者更便宜。
融资历史本身就是信号
这轮融资是在 Supabase 于 2026 年 6 月完成 5 亿美元 F 轮融资四个月后到来的，该轮融资对公司的投后估值为 105 亿美元，同样由 GIC 领投。在那之前，是 2025 年 10 月按 50 亿美元估值完成的 1 亿美元 E 轮融资。总融资额现在已超过 10 亿美元。
这么快再次融资，表明公司要么想要资金，要么想要一个头条新闻，而新闻稿称，本轮融资的一部分为员工提供了流动性。在这个阶段，面向员工的二级交易成分是正常的，值得将其与公司实际投入运营的现金区分开来。
战略逻辑比财务逻辑更清晰。Supabase 希望成为当项目需要后端时，开发者或智能体首先求助的地方。如果该项目最早的版本是智能体创建的一个微小 SQLite 数据库，那么拥有创建时刻就意味着在竞争对手看到这个项目之前就拥有了这段关系。此后，当应用程序超出轻量级层级时，Supabase 提供一条进入标准 Postgres 的升级路径。Turso 将继续作为平台运行，其代码库保持开源。
整合模式
Supabase 并非唯一采取这一举措的公司。Restate 本月完成了由 Singular 领投的 2000 万美元 A 轮融资，用于构建持久基础设施，防止长时间运行的智能体工作流在任务中途失败。LlamaIndex 发布了一款基于模式的文档提取工具，面向智能体数据管道。这些交易的主题是，智能体底层的管道正在成为一个品类，而其中以前属于事后考虑的部分现在获得了融资。
对于构建者来说，实际问题是会有什么变化。现有 Supabase 用户被告知他们不会看到任何差别，对于一个现在在同一屋檐下运行两个引擎的平台来说，这是正确的回答。更具影响的转变在于默认设置。如果 Postgres 和 SQLite 都生活在同一个生态系统中，那么二者之间的选择就变成了关于工作负载形态的决定，而不是关于供应商的决定，并且廉价选项会在智能体需要它的那一刻就可获得，而不是在采购周期之后。
仍然悬而未决的是，这种经济性是否成立。每个智能体一个数据库的模式只有在存储、配置和支持成本低于客户愿意支付的价格，并且有足够多的这类数据库成长为付费的生产工作负载时，才可行。Supabase 押注答案是肯定的，并且值得保留的项目会从小规模开始。