六年前，Paul Copplestone 和 Ant Wilson 刚从 YC 毕业，在新加坡的一间小公司里庆祝着被 Hacker News 用户"意外"推上首页的那次冷启动。如今，他们坐在 Latent Space 的录音间里，准备在 Supabase Select 2026 大会前夕，一次性公布三项足以改写 Postgres 生态格局的技术突破。这场对话没有停留在成功故事的表面，而是直接切入了一个更硬核的问题：当 AI agent 开始大规模生成应用、数据库数量要从每月 500 万冲向数十亿时，后端基础设施到底需要变成什么样子。
Paul Copplestone 是 Supabase 的联合创始人兼 CEO，Ant Wilson 则负责公司的技术方向。两人这次带来的不是渐进式的功能更新，而是关于计算、存储引擎和分片架构的三重根本性改造，外加一笔刚刚敲定的收购。
1. 一个不再被 2 秒超时锁死的计算层
Supabase 此前的 Edge Functions 产品跑在 Deno 之上，但有一个硬性限制——函数执行时间不能超过两秒。这个限制卡住了社区很久以来反复提出的需求：分块处理、生成 embedding、运行更长的任务链。于是团队推出了 Supabase Compute，一个无服务器、长时间运行、且与数据库部署在同一私有网络里的计算实例。
这不再局限于 Deno，你可以用 Rust 或 Python，甚至在里面直接跑 agent。与同类云服务对比，这更接近"容器化的 Lambda 函数"——但因为和数据库共享网络环境，延迟表现要好得多，Postgres 连接可以直接从计算层发出，不用再绕一层网络跳转。对于正在把更多业务逻辑交给 AI agent 处理的团队来说，这意味着后端第一次有了一个专门为长任务和 agent 工作流设计的计算位置。
2. Oriole DB：把存储引擎换掉，却什么都不用改
第二项发布是 Oriole DB，一个作为 Postgres 默认存储引擎 heap 的完全替代品。团队去年就提出了这个方向，但过去一年的工作重心全部放在打磨稳定性上——用 PG regress 做兼容性测试，用 antithesis 做故障注入，用 TPCC 做夜间基准测试，再叠加 Jepsen 验证数据一致性，目的只有一个：确保它永不丢数据。
结果是一个性能提升 1.5 到 2 倍、且完全兼容现有 Postgres 生态的引擎，用户不需要改动任何代码。它还顺带消除了 vacuum 这类后台维护任务的开销。更值得注意的是商业条款：Supabase 收购了这项技术并持续开发，随后买下了相关专利，现在把它以 Apache 2.0 协议完全开源，专利风险也随协议一并覆盖。
3. Multigres：从"每个 operator 都会丢数据"到一千次故障切换零丢失
真正让人意外的细节出现在团队调研 Postgres 生态现有 operator 时的发现——几乎每一个 operator 在某些条件下都会丢数据。这成为 Multigres 项目的起点：一次对 operator 架构的彻底重写，目标是为 Postgres 社区带来真正可靠的分片能力。
这个项目的技术血统来自 Sugu，他曾为 MySQL 生态打造了 Vitess。这次他给 Multigres 定下的第一原则是"兼容性优先"：以往用 Vitess 做分片时，用户往往需要为了迁移改写查询语句，而这次的目标是让用户在数据库分片后不需要改动任何代码，继续跑原来的查询。
团队已经对 Multigres 做了一千次连续故障切换测试，没有丢失任何数据。项目完全开源，目前以邀请制方式在 Supabase 平台上向部分客户开放，设计合作伙伴包括 Booz Allen、Postman 和 Perplexity。真正的分片能力预计明年初上线，届时这将补齐 Postgres 对抗 MySQL 生态的最后一块拼图——毕竟 YouTube、GitHub 这些超大规模系统至今仍跑在 Vitess 之上的 MySQL 体系里。
4. 收购 Turso：为了十亿级数据库，必须先想明白"文件格式"
如果说前三项是对现有架构的加固，第四项宣布则是一次路线分叉。Supabase 目前每月在平台上启动约 500 万个数据库，但团队判断未来需要支撑的是每月数十亿的量级。这种规模跳跃不能靠现有架构硬扛，需要全新的思路——于是 Supabase 宣布收购了 Turso。
Turso 的底子是 SQLite，但团队强调真正重要的不是数据库引擎本身，而是其背后的架构思路。SQLite 原生只支持单一写入者，这一限制逼着 Turso 团队——他们最早从 libSQL 做起，还因为 SQLite 的许可证问题 fork 了一版——构建出一套为 SQLite 实现 MVCC 的架构，让多写入者成为可能。有意思的是，这套思路和近几个月 S3 对象存储新增的特性讨论高度重合：对象存储凭借 11 个 9 的数据持久性，已经可以在一定程度上充当数据库的底层集群，只是在事务密集场景下的读写性能仍有局限，这也是为什么大规模事务型负载仍要靠 Multigres 来扛。
真正触发收购决定的，是 Turso 的一篇博客——详细描述了他们如何重写架构，从而为 SQLite 文件格式打开了兼容 Postgres 的路径。收购后 Turso 品牌将被保留，继续专注 SQLite 方向，同时 Supabase 将推出一个全新的轻量实例类型，名为 Supabase Spark，与现有所有库完全兼容。开发者可以用它跑任何原型或想法，一旦某个应用真正起飞，就能无缝升级到完整的 Postgres 数据库，直至 Multigres 支撑的分片规模。
5. 小应用的秘密：在爬到 Hacker News 首页之前，你不知道自己需要什么
这项收购背后其实藏着一个关于规模本质的观察：在通往数十亿数据库的路径上，绝大多数数据库其实都很小。它们是 vibe coding 出来的原型应用，体量微不足道——直到某一天真的被用户注意到。团队提到一个具体的危险时刻：一旦某个项目冲上 Hacker News 首页，流量会瞬间远超原有架构的承载能力。
这正是零停机迁移要解决的核心问题——确保从轻量实例到完整 Postgres 再到分片集群之间，有一条真正平滑的升级路径，而不是让开发者在流量爆发的那一刻措手不及。
六年前的那次 Hacker News 冷启动，让 Supabase 从一个新加坡小团队走到了今天站在十亿级数据库门口的位置。Compute 解决了 agent 时代长任务的计算位置问题，Oriole DB 解决了性能，Multigres 解决了可靠性与分片，Turso 收购解决了规模的下限问题——四项发布拼在一起,回答的其实是同一个问题：当 AI 把应用生成的门槛彻底拉低之后，后端基础设施该如何既托得住海量的小型原型，又能在它们成长为真正业务时无缝接住。