摘要：2026 年 10 月 2 日，Supabase 在官方博客宣布收购 Turso——SQLite 的 Rust 重写版本及其云端平台背后的团队。Supabase 官方给出的理由很直接：Agent 会创建海量数据库，Postgres 服务规模化应用，而 SQLite 适合按需现开。官方同时表示，现有 Turso 用户"一切照旧"。
导语：过去一年，数据库这个环节最明显的变化不是更快了，而是"数量变多了"。当一个 Agent 会话、一个分支预览、一次代码评审都想拥有自己的数据库时，为每个实例跑一套 Postgres 的成本结构就不成立了。Supabase 这次的动作，本质上是给这条新需求准备第二套引擎。
发生了什么：买下的是一支团队和第二个引擎
按 Supabase 官方博客的表述，被收购的 Turso 是"SQLite 的 Rust 重写版本，以及一个单台服务器就能管理数百万个数据库的云平台"背后的团队。这个描述里有两个词值得拆开看：Rust 重写意味着它不是简单地把 SQLite 塞进容器，而是重做了一层可以在服务器侧大规模调度的实现；单机数百万库意味着它的成本模型是按"库"而不是按"实例"算的，这恰好是 Agent 场景需要的粒度。
官方对 Turso 的能力描述是"按需为每个 Agent 配置一个数据库"，并且这些库可以开在 Turso Cloud 上，也可以开在"客户自己的云"里。博客里列出的 Turso 客户包括 Superhuman、Sauna.ai、CTO.new 和 Mastra。人员方面，Supabase 明确欢迎 Glauber Costa 和 Pekka Enberg 与 Turso 团队其余成员一起加入，并说明 Glauber 将负责这条 agentic infrastructure 方向。
几个必须如实说明的缺口：官方博客没有披露收购价格、交易结构或交割时间，也没有给出任何 quotes 形式的引语，整篇文章的作者署名是 paul_copplestone。文中唯一的具体数字是 Supabase 自己的运营数据——"每周已经开出超过一百万个数据库"。这是产品方自述的数据，不是第三方审计结果。
一个完整场景：为每个 Agent 会话现开一个库
设想一个正在被大量团队采用的模式：开发者让编码 Agent 修一个涉及数据迁移的 bug。Agent 需要真实的数据、需要能跑迁移脚本、需要能在搞砸之后把状态回滚。稳妥的做法是给它一个一次性数据库——会话开始创建，会话结束销毁，失败了直接丢弃，不污染任何共享的测试环境。
在纯 Postgres 的路径上，这件事的摩擦点在"准备一个 Postgres 实例"本身：连接数、初始化时间、以及一台机器上能跑多少个实例。Supabase 博客里点出的正是这个结构性问题——Agent 创建的负载天生更碎、更短命，而 SQLite 这种"文件即数据库"的形态，天然适合按需创建和直接丢弃。官方给出的方向是让两种引擎各管一段：Postgres 承载需要规模化和长期演进的正式应用，SQLite 承载 Agent 生成的海量短命库，而开发者面对的是同一套 Supabase 体验。
为什么它改变工作流：数据库从"基础设施"变成"会话级资源"
如果把这次收购放到开发者工作流里看，变化不在于某个 API 变快了，而在于"开一个数据库"这个动作的成本位置变了。当一个库可以按会话创建、按会话销毁时，数据环境就不再是需要提前申请的共享资源，而变成可以随任务一起产生和回收的临时产物。这会直接改变 CI、预览环境和 Agent 沙箱的做法：以前这些场景共享一个测试库，靠 schema 隔离或前缀区分；以后更自然的做法是每个任务独占一个库，用完即弃。
对已经在用 Supabase 的团队来说，更现实的影响是"第二引擎"会以什么形态出现在产品里。官方目前给出的承诺只有方向性的：围绕 Postgres 继续建设，Turso 继续做它的 SQLite 工作。换句话说，这不是把 Postgres 换成 SQLite，而是在同一套开发体验下增加一个更适合短命负载的选项。具体到 SDK、Dashboard 和 CLI 上会怎么呈现，官方博客没有给时间表。
边界：价格未披露，"用户不受影响"是官方单方承诺
有三条边界需要摆在明面上：
- 没有任何交易条款。价格、股权或现金比例、交割时间全部未披露，因此无法判断这笔交易的规模，也无法判断整合的深度。
- "现有用户不受影响"是 Supabase 的单方表述。原文是"For existing users, nothing changes."，这是被收购方与收购方共同的对外口径，不是合同条款，也不是可验证的技术承诺。Turso 用户应当按"供应商可能变化"来评估自己的锁定风险。
- 产品整合尚无时间表。官方没有说明 Turso 的能力何时会出现在 Supabase 的 Dashboard、CLI 或 SDK 里，也没有说明自托管版本如何受益。
人需要接管的判断点也很明确：把哪些数据放在 SQLite 这种按会话创建的库上，是一个架构决定，而不是产品能替你做的决定。持久化状态、需要事务跨会话一致的数据、以及需要审计留痕的数据，仍然应该留在 Postgres 一侧；把长期数据放进一个"会话结束就销毁"的库里，是这类新能力最容易踩的坑。
如何试用
这次收购本身没有给开发者提供新的入口，可以做的动作有两个方向：已经在用 Supabase 的团队，可以先在现有项目里梳理出"适合一次性环境"的负载清单——参考数据、迁移验证、Agent 沙箱这类场景，为将来的按会话建库做准备；已经在用 Turso 的团队，官方承诺现有服务继续运行，并且"随着负载增长有一条进入更广泛 Supabase 生态的清晰路径"，短期内不需要迁移，但值得把这次变更记进供应商风险清单。
信息来源
- Supabase Blog，2026-10-02，Supabase is acquiring Turso（作者 paul_copplestone）：
https://supabase.com/blog/supabase-is-acquiring-turso
说明：本文中的收购对象、客户名单、人员安排与"每周超过一百万个数据库"均来自 Supabase 官方博客；该数字为产品方自述数据。价格与交割时间官方未披露，本文不作推测。
HiFox：将 Agent 变成真正的队友
另外，我们也在思考，AI 如何从个人提效走进团队协作。
HiFox 是一个让人和 AI Agent 在同一个工作现场协作的平台：你可以像给同事分派任务一样指派 Agent，在任务看板中跟踪进度、查看结果，让 Agent 成为团队里的队友。
👉 立即体验 HiFox：https://hifox.com
AI Coding 交流群
如果你也在用 AI 写代码，或者正在研究 Cursor、Claude Code 这些工具，
欢迎加入以下交流群。群里平时会聊一些 AI 编程的实际用法、开发工作流，还有各种新工具和新玩法。
