同一天里，Supabase 拿了 1.5 亿美元，又买下了一群用 Rust 重写 SQLite 的人。这不是补产品线，是在赌数据库的创建单位会从"每家公司一个"缩到"每个 Agent 一个"。
10 月 2 日，Supabase 干了两件事。
一件是拿了 1.5 亿美元新融资，新加坡主权基金 GIC 领投，Alphabet 旗下的 CapitalG、IronArc、SquarePeg 跟投。另一件是宣布收购 Turso，价格没披露。
前者好懂，钱嘛。后者就有意思了。
Supabase 是现在最有名的 Postgres 平台之一。Turso 是一群把 SQLite 用 Rust 从零重写了一遍的人。一家做关系型数据库的公司，去买一个做嵌入式数据库的团队——这不太像补产品线。
它更像换了一个问题在问自己：如果未来的数据库数量不是几十万个，而是十亿个，那它该长什么样？
这篇文章用六个问题拆开这笔交易：Agent 把数据库用成了什么样、Turso 到底做对了什么、Postgres 为什么不算输、这笔钱真正在赌什么、赌注的风险在哪、以及对手在做什么。
先看一组数字，它们才是这笔交易真正的动机。
Supabase 自己在博客里写：现在每周新建超过 100 万个数据库。到了 10 月的新闻口径，是每月新增 100 万以上用户、400 万个以上数据库，其中约 70% 的新库由 AI 工具创建。截至今年 6 月的过去一年，数据库创建量同比涨了 600%。
Turso 官方点名的客户名单里，Superhuman、Sauna.ai、Mastra 都在按需给每个 Agent 开库。其中最直白的案例是 Engine Labs 做的 CTO.new：它给每个项目配一个 Turso 库当多 Agent 的协调层，跑着数万个数据库，服务 5 万多用户。
它原来用 Supabase，每个用户每月约 $20。迁到 Turso 之后，边际数据库成本从 $20 掉到大约 1 美元，整体降了约 95%。它的月费套餐是——500 美元。
这才是变化的核心：数据库的创建单位变了。
人类开发者建库，基本是"一建管好几年"。一个产品、一个租户、一套表结构，改起来慎之又慎。
Agent 不这样。它会为一次原型、一次探索、一个临时看板、一个单任务草稿，各建一个库；任务结束，这个库就没用了，扔掉。你可以想象这个动作：某个 Agent 接到一条指令，第一步是建库，最后一步是删库——中间它甚至没让人类看一眼。整个过程，像新建一个临时文件一样自然。
老的数据库模型撑不住这个用法。原因是：过去每一个小负载，背后都隐含着一台为你长驻的机器。你要么为它付一台服务器的钱，要么等它被调度起来。前者太贵，后者太慢。
所以问题被推到了基础设施这一层：能不能做到"建库如建文件"，而且几乎不用关心成本？
一句话答案：它把数据库从"一个服务器进程"，变回了"一个文件"。
这不是营销话术，是 Turso 整个技术路线的内核。
团队的前身是 ChiselStrike，2021 年成立，创始人是 Glauber Costa 和 Pekka Enberg。两人都是系统底层出身，Glauber 在 Linux 内核、ScyllaDB、Datadog 干过 25 年。他们最早的选择是 fork 一份 SQLite，做成开源项目 libSQL。
后来发现这条路不够。libSQL 的向量搜索只能靠独立表加显式 JOIN，语法别扭；更麻烦的是 SQLite 官方测试套件是专有的，代码又是 C 写的，想大改心里没底。于是 2024 年 12 月，他们做了一个更狠的决定：用 Rust 把 SQLite 从零重写一遍，代号 Limbo。目标是在 SQL 方言、文件格式、C API 上完全兼容，但内核是内存安全的、现代化的。今年 3 月，首个支持并发写、CDC、原生向量搜索的版本发布。
真正的工程创新在"盘"这一层——Turso 把它叫做 diskless。
传统数据库把本地磁盘当成"状态的家"。Turso 反过来：计算节点完全无状态，本地 NVMe 只当读缓存，S3 Express One Zone 才是所有已提交事务的唯一真相来源。压测数据（4KB 操作、同可用区）是：S3 Express 的 PUT 平均 6.4ms，对照本地 fsync 的约 2ms——在 4KB 这种小操作上，只多花了大约 4ms。换成标准 S3，同样操作平均要 31ms。
写路径也做了取舍：事务先在内存里跑完，然后等几毫秒，把同一个节点上多个库的 WAL 合并成一次 S3 PUT，收到成功应答再回执给客户端，同时写本地 NVMe 供读。
这一套组合拳，带来三个别人很难同时给的结果：
再加一个关键补丁：SQLite 的老毛病是单写入者——一个写事务独占全局锁，加线程也提不上吞吐，还容易撞上 SQLITE_BUSY。Turso 用受 Hekaton 启发的 MVCC 实现了 BEGIN CONCURRENT：写事务并发跑，只在提交时对双方都写到的行做冲突检测。官方实测，在"每事务 1ms 计算、8 线程"的场景下，写吞吐大约是 SQLite 的 4 倍。
还有两个容易被忽略但很关键的细节。文件被切成 128kB 的 segment，一组 segment 构成一个 generation，分支只是一次元数据操作，几乎瞬间完成；这就是它能"每个 Agent 一个库、还能随便复制"的底层原因。另外它支持 BYOC（整套 Turso Cloud 跑在客户自己的 AWS 账户里）和 BYOK（每个库独立密钥加密，密钥对 Turso 不透明）。
CREATE INDEX，行版本内存开销也不小；Rust 重写版官方自己也说"尚未到 1.0"。它是为"海量小库"设计的，不是为替代所有数据库。因为这两样东西，服务的根本不是同一段路。
Supabase 的官方叙事很克制：Supabase 继续做 Postgres，Turso 继续做 SQLite。两者的分工是——SQLite 适合小而按需的负载，Postgres 适合应用规模化之后的负载。目标是让开发者从原型到生产，用同一套体验。
把这条线拉直，就是一个分层的"毕业路径"：
同一套开发者体验，从"建库如建文件"一直铺到 PB 级。这张图，就是 Supabase 想卖给 Agent 的东西。
图里下半段那两个东西，是 Supabase 今年 10 月 Select 大会一起发布的。
Multigres 是一套开源的 Postgres"操作系统"，出自 Vitess 团队之手（Glauber Costa 也参与其中）。它在同步复制之上加了一层共识协议，节点故障时能秒级提升副本、已提交的写入不丢，应用不用改代码；未来版本还会给出 Vitess 级别的水平分片。目前是 v0.1 alpha。
OrioleDB 则是换掉了 Postgres 的老存储引擎：用 undo log 取代传统 heap，把表膨胀、VACUUM 开销、32 位事务 ID 回卷这些老问题一起拿掉，默认走 64 位 XID。官方给的 TPC-C 衍生基准里，吞吐最高提升 1.8 倍。
所以逻辑闭环是：Agent 第一次建库，落在 Turso 上；当它长大，迁到 Postgres；再大，交给 Multigres。
但这里必须把 Turso 的边界也说清楚。第三方评测的结论是：真正需要高并发多进程写入、数据集超过数 GB、或者要跑复杂分析查询时，还是该回到 Postgres——它的查询规划器更强。Turso 的甜点区是 AI Agent 的记忆与状态、多租户 SaaS 的每租户一库、边缘低延迟读、local-first 与端侧 RAG。
拆开来是两件事，但它们是同一个赌注的两条腿。
第一条腿，赌"建库经济学"成立。
Turso 把自己的架构总结成一句话："数据库是一个文件，而不是一个长期运行的服务器进程。"当建一个库的边际成本趋近于零、闲置时又几乎不花钱，一个组织就不再需要把所有数据塞进一个大库。它可以把数据按最自然的边界切开——每个租户、每个会话、每个任务、每个 Agent，各一个库。
这不是新的查询语言，也不是新的数据模型。它动的是数据库的物理部署单位和生命周期。
第二条腿，赌"入口"。
Supabase CEO Paul Copplestone 的话说得很直白：
翻译一下：谁定义了 Agent 第一次建库的体验，谁就很可能拿到它后端的第一入口。SQLite 是那扇门，Postgres 是门后的主库，中间的 Auth、Storage、集成生态和 MCP，是把用户留在院子里的东西。
Turso 创始人 Glauber Costa 的表述更露骨——他从创业第一天起的目标，就是服务十亿个数据库。他加入 Supabase 后的头衔是 Head of Agentic Services。他还在技术博客里提了一个新维度：数据库的可扩展性，以前看两件事——能存多少数据、查询多快；现在要加第三件——能多快配置、管理多少个数据库。
技术和愿景都讲得通。麻烦在账单，和那张还没写出来的迁移表。
第三方分析把担忧集中在这几点，而这几点的共同特征是——官方公告里一个字都没提。
第一，价格与关键条款全缺。收购价格没披露，交割日期没有，SLA 没有，现有套餐的延续承诺也没有。Turso Cloud 的定价会不会延续、免费额度怎么算、SQLite 迁到 Postgres 要花多少钱、数据范围多大——公开信息里都是空白。
第二，两套计费模型对不上。这是最实际的问题。Turso 的 Developer 套餐是 $4.99/月、不限数据库；而 Supabase Pro 是 $25/月，含 $10 计算额度——大概只够一个 Micro 实例，多加一个项目就要另付算力费。
第三，开源中立性。官方说"开源保持开源"，Turso Database 会继续开源。但底层引擎正在换代——MIT 仓库里写着 Rust 重写"取代 libSQL"是既定方向，而重写版"尚未到 1.0"。那些自托管 libSQL 的人，已经站在公司明说要离开的那条分支上。一家同时持有主流 SQLite 引擎项目的公司，本身就是个治理问题。
第四，有前例可循。2025 年 1 月，Turso 曾为新用户下线 edge replicas、移除多库 schema 与 ATTACH，当时的承诺也是"现有生产负载照常运行"。结果呢——现有负载确实被保护了，但卖给下一个客户的产品，变了。对老客户的承诺和对新客户的承诺，从来不是一回事。
所以第三方给客户的建议很务实：导出完整的数据库清单与规模、在 Turso Cloud 之外做一份独立备份、书面向对方索取交割日期和至少 12 个月的价格锁定，并在合同里加"控制权变更"条款。
有意思的是，收购方有时会给惊喜。Databricks 去年 5 月收购 Neon 后，三个月就转向了按用量计费、取消月最低、扩大免费额度。但那是"有时"，底价还是得落在纸上。
把镜头拉远，"每 Agent 一库"是整个行业的共识方向，只是每家的路线不同。
| 玩家 | 底座 | Agent 方向的打法 | 差异点 |
|---|---|---|---|
| Supabase + Turso | Postgres + SQLite | 每周新建 100 万+ 库；"每 Agent 一库 + 毕业到 Postgres" | 双栈分层，覆盖从入口到 PB 级 |
| Cloudflare | Durable Objects + 隔离 SQLite | Agents Week 2026 推 Facets，每个 AI 生成的应用实例化独立库 | 算存同置，但与 Workers 深度耦合、文件不可带走 |
| Neon + Databricks | Serverless Postgres | 2025 年 5 月被收购，理由是"80%+ 库由 AI Agent 创建" | 完全云端，本地运行时拿不到本地副本 |
| AWS Aurora | Serverless Postgres | Aurora Serverless v2 更名，Aurora DSQL 配 Bedrock AgentCore | 仍是云托管服务，单库成本模型 |
| PlanetScale | Postgres / MySQL | 与 Cloudflare Workers 集成 | 偏传统托管，不主打密度 |
| libSQL | SQLite fork | Turso 的起家产品，原生复制 + 向量搜索 | 已被 Rust 重写版取代为既定方向 |
看这张表会发现两件事。
一是方向已经确定：Neon 被收购时，理由是"80% 以上的库由 AI Agent 创建"；Cloudflare 直接把库塞进每个 AI 生成的应用实例；连 AWS 都在把 serverless 讲成"大多数新应用的默认"。没人还在争"Agent 要不要数据库"。
二是路线分歧还在。Cloudflare 走的是算存同置，代价是库和它的运行时绑死，文件拿不到本地；Neon 走纯云端多租户，但 AI 在本地跑时拿不到本地副本；而 Turso 的差异化甜点是——库能被塞进任意沙箱，断网也能读写，重连后再增量推回云端。
这个分歧很关键。它决定了"每 Agent 一库"最终的形态：是每个库都住在一个云服务的机房里，还是每个库都能像文件一样被 Agent 随身携带。
对开发者来说，这笔交易的短期影响，其实比新闻标题要小得多。Turso 照常运行，数据库、API、工作流都不变。Supabase 也不会明天就把你的 Postgres 换掉。
真正需要盯的只有两件事。
第一件是账单。那套 $4.99 不限库的定价还能不能留——如果留着，它是这个行业里最便宜的"每 Agent 一库"方案；如果被并进按算力计费，算盘就得重打。
第二件是工具。所谓"从 SQLite 毕业到 Postgres"的水到渠成，现在是一句话，不是一个工具。等它变成真的迁移器再说。
至于赌注本身，它成立与否不取决于发布会说了什么，取决于一件很朴素的事：当数据库的数量从百万涨到十亿时，那张账单还能不能算得清。