Supabase四连发：换掉Postgres存储引擎，收购Turso押注SQLite

Supabase 用六年时间，从一个在 Hacker News 上被陌生用户"软启动"的数据库项目，长成了每个月上线 500 万个数据库的平台。在自家 Supabase Select 大会前夕录制的这期 Latent Space 里，联合创始人 Paul Copplestone 和 Ant Wilson 一口气交出了四份公告。

四件事指向同一个命题：Postgres 长期被诟病的三块短板——单机性能、向上扩容（scale up）、向外扩容（scale out）——能不能一次补齐。他们的答案分别是 OrioleDB、Multigres，以及一笔对 Turso 的收购。更关键的是，其中相当一部分成果被选择开源，交回给整个 Postgres 社区。

这场对话在大会前录制、会后发布。主持人与这两位创始人认识六年，那时候他们刚走完 YC，正在新加坡庆祝。

1. 把只有几秒额度的 Edge Function，换成完整容器

Supabase 现有的 Edge Functions 由 Deno 驱动，执行时长上限很短。社区催了很久：他们想跑更长的活，比如给文档分块、生成向量嵌入，这些任务天然塞不进几秒钟的窗口。

Supabase Compute 就是答案。它长时运行、serverless、容器形态，而且和数据跑在同一个私有网络里——同处一地意味着延迟很低，你可以直接从 Compute 里建 Postgres 连接；语言也不再限定 Deno，Rust、Python 都能用，Agent 可以直接跑在里面。

用其他云的说法类比，它接近"容器版的 Lambda"，区别在于它从设计上就和你的数据库住在同一张私有网络里，而不是隔着一层公网。

2. OrioleDB：不改一行代码，快 1.5 到 2 倍，然后免费送出去

OrioleDB 是 Postgres 现有存储引擎 heap 的直接替换件（drop-in replacement）：性能大约快 1.5 到 2 倍，业务侧不需要改任何东西。它还把 vacuum 这类后台任务的需求彻底消掉了，对数据库本身也更省资源。

过去一年，Supabase 把它"过了一遍筛子"——用 pg_regress 验证与 Postgres 的完整兼容，跑 TPC-C 夜间基准，再上 Jepsen 压测，确认它在任何情况下都不会丢数据。

明天它将进入 full beta，同时采用 Apache 2 许可证，专利也一并被覆盖。"我们收购了这项技术，继续开发它，付掉了专利费，现在把它免费送出去。"

3. 几乎每一个 Postgres operator，在特定条件下都会丢数据

Postgres 从单节点起步，但要上规模就需要多节点、故障转移、备份——这些通常交给一个叫 operator 的组件统一接管。Supabase 把生态里的 operator 挨个试了一遍。

结论很不好听：在特定条件下，每一个都可能丢数据。于是他们决定推倒重来，从零重写整个 operator 的结构，这就是 Multigres。

它的初始目标只是给 Postgres 社区补上分片能力，最后却长成了一整套"操作系统"。测试标准也随之拉满：1000 次连续 failover 没有丢过数据，团队还用各种能想到的方式去"砸"它，只为确认它不会在任何情形下丢数据。

一个关键取舍来自 Vitess 的创建者。Vitess 当年为 MySQL 生态解决分片，团队却总在补兼容性——迁移到分片时不得不改查询。他的建议是先把兼容性做到底。Multigres 因此被设计成：分片上线那天，你的查询一行都不用改。

发布方式是开源，客户侧邀请制，先服务跑严肃负载的团队。设计伙伴计划里已经有 Postman、Perplexity 这类名字——需要它的人，都是正在大规模运行 Postgres 的人。

4. 每月 500 万个数据库之后，是每月数十亿个

Supabase 平台上每个月要新开约 500 万个数据库。顺着现在的曲线，他们认为终点是每月数十亿个——而这一批数据库大多很小，很多只是一个刚起步的原型。

这个体量下，老路子走不通。他们把目光转向"agentic 数据库"这条新架构，并宣布收购 Turso。

SQLite 本身只支持单写者，本质上是一种文件格式；Turso 为它补上了 MVCC，让多写者成为可能。SQLite 的授权方式比较特殊，他们不得不 fork（最早基于 libSQL）。更巧的是，对象存储最近新增的一批能力，让 S3 这类存储可以被当作数据库的底座使用——11 个 9 的持久性虽然不是"可靠性"，但足够充当集群下面那层地基。它的短板在事务：交易型数据库要承受大量读写，超大规模负载仍然要靠 Multigres；但对"要冲到数十亿个库"的场景来说，数据库最好本身就是一个文件格式，SQLite 恰好符合。Turso 团队发布的重写方案，给了 Supabase 一条让 Postgres 兼容这种文件格式的路径。

收购之后 Turso 品牌保留，继续聚焦 SQLite；Supabase 则推出一种更小的实例类型 Supabase Spark：任何一个想法、任何一个原型，都可以先拿到一个数据库，兼容全部现有 library。等它真的火了，再升级成完整的 Postgres，一路可以走到 Multigres。

5. 从 Spark 到 Multigres，升级路上不该有停机

"一旦你上了 Hacker News 首页，你得知道你还能走多远。"这句话解释了 Supabase 为什么必须同时做 scale up 和 scale down——后端之间必须有一条平滑的迁移通道，而且需要的是零停机迁移。

把四项公告串起来看，这条通道的形态就清楚了：起步时是一个 Spark 实例，长大之后换成完整 Postgres，再往上接到 Multigres。在这套设计里，零停机迁移已经不算加分项，而是必需品。

一块算力、一个存储引擎、一套 operator、一次收购，四件事拼出的其实是同一个野心——补上 Postgres 在云上最缺的几块拼图。而 Supabase 的选择是，把这些拼图大部分做成开源，交回给整个生态，即便用的人未必是它的客户。

六年前那家在新加坡庆祝 YC 毕业的数据库公司，如今赌的是另一件事：当每个月要开出数十亿个数据库时，赢家不会只有一个平台。