欢迎：智能体为何喜欢 Supabase
又是我。希望大家喜欢我们最近做的这些短片头。这样我也能稍微和大家聊聊，我们为什么做这些节目，以及在访谈里有哪些内容值得留意。我们会继续推出更多音频访谈，也会加入屏幕上弹出的图层，让画面更有意思；对于刚入行的人来说，有些背景知识可以通过这些图层解释，我在访谈过程中没法把每件事都讲一遍。
我最近参加了 Supabase Select，也就是 Supabase 的公司大会。有很多内容值得聊。首先我想说明，我和这家公司关系很近：六年前我在他们的种子轮做了天使投资，这是我第一次做天使投资。他们发展得非常好，六年里估值从零到了 100 亿美元。Supabase 是一家规模很大的全远程开源公司，几乎正在成为托管 Postgres 的行业标准。我想拆解一下他们为什么能做到这一步、这家公司是怎么运转的。我也想看看，为什么他们在我的 AEO 排名里表现那么好；这可不是理所当然的。许多公司都在争夺“为智能体构建数据库”这件事。
我记得他们也是 2023 年第一届 AI Engineer 大会最早的赞助商，现在又将成为 Latent Space 的首家赞助商。我们开放赞助，和熟悉、信任、也能向听众讲清楚的公司和人合作，当然再合适不过。我想重点聊的内容，他们在 YouTube 上做了很出色的大会回顾；大会围绕 Build、Operate、Scale 三个主题展开。我觉得这些发布很符合我对公司大会主题演讲的期待。
Build 主要是改善编码智能体搭建 Postgres 应用的体验。有两项让我印象特别深。第一项很简单：启动 Supabase 不需要 Docker。启动基本流程、连接数据库所需的额外负担越少越好；以后当然还可以扩展到完整的虚拟机。第二项是 Supabase Compute，也就是在数据库旁边运行计算任务。我觉得把计算放在一起非常方便，这一点其实被严重低估了，大家可能还没充分意识到它的潜力。让应用拥有来自 Supabase 的 MCP 服务器也很有用。
不过，声明式 Schema 同样重要。我们想要声明式 Schema，而不是传统 SQL 的那套流程：先建 Schema，然后一次又一次地迁移。我们在节目里也会谈到这一点。所有东西都应该放在 Git 里，作为事实来源，让智能体能读取、理解，然后从那里搭建、分叉项目等等。这听起来简单，但 Postgres 本来并不是为此设计的。你得把这些功能改造到一套已有四十多年历史的数据库上。
我现在把 Supabase 的势头看作是在为智能体使用 Postgres 补上最后一公里，推动 Postgres 面向智能体的前沿发展。妙处在于，这其实并不是专门为了智能体——我们一直都需要这些功能。人也会因此受益，我很喜欢这一点。我不喜欢只做让智能体满意的东西。
第二部分是 Operate，主要是给智能体更多上下文：更多日志、检查、连接，甚至是用于 SQL 的 Markdown 文件（笑）。这很酷。他们每年都会发布一些有意思的数据管道相关工作，从 Stripe 到其他各种系统……
规模化与数据库工程
……各种集成。我觉得，随着你在 AI 工程领域越做越深入，通用的 ETL 问题也会越来越成为数据工程技术栈的一部分。现在 Supabase 有了自己的官方方案，你可以混合使用两种方式，按需选择；不过有时所有东西都在一个平台上确实更方便。
最后一部分也许最复杂，讲的是大规模扩展。这就是 Supabase 把品牌口号从“原型到 PB 级”改成“从原型到 PB 级”的原因（笑）——他们显然正朝着更大规模发展，因为客户数量也在增长。他们宣布 Multigres 正式推出 1.0 版。这算是他们面向 Postgres 的 Vitess 移植方案，由 Vitess 的原班人马参与；这在数据库领域是件大事。如果你还不知道 Vitess，那可就错过不少了，得了解一下。你现在正在 YouTube 上看这个节目，而 YouTube 就运行在 Vitess 上。
OrioleDB、数据库，还有很多内容值得展开。说实话，从我和创始人的关系也能看出来，这是他们两个人第一次一起接受访谈。我会提到这一点，也会让大家看看他们之间的默契，感受一下经营一家估值 100 亿美元的数据库公司的对话是什么样子。请欣赏。
Paul Copplestone 与 Ant Wilson
好，这期播客筹备了六年（笑）。很高兴请到 Coppel 和 Ant 来到录音室，欢迎二位，谢谢你们。
谢谢邀请。
我们是在 Supabase Select 之前录制的。那是你们的大型客户大会，这期节目会在大会之后发布。我想借此回顾一下你们走过的历程。我从你们结束 YC 创业营后就关注你们了。那时你们在新加坡的一个地方庆祝，我第一次见到你们，心想：这家突然在 Hacker News 上被某个用户悄悄发布的数据库公司怎么这么火？总之，祝贺你们取得的所有成绩。Select 上要宣布的重磅消息有哪些？我们直接聊吧。
好的，确实有不少重要消息，内容很多。首先是计算。我们有一款叫 Edge Functions 的产品，由 Deno 提供支持，基本上有 2 秒的执行时限。社区很早就告诉我们，他们希望能运行……
数据库旁的计算能力
社区希望运行时间更长的工作负载，比如分块和生成嵌入。因此，明天我们会宣布——等节目播出时已经发布了——Supabase Compute。你可以在上面运行任何东西：它支持长时间运行，是无服务器的，和数据库处于同一个私有网络里，因此部署位置相邻、延迟很低。你可以直接从计算环境建立 Postgres 连接，在里面运行任何程序，不再受限于 Deno，也可以用 Rust 或 Python，甚至在里面运行智能体。基本上，它就是一个完整的计算实例。
如果和大家熟悉的其他云服务比较，它大概相当于什么？
有点像 Lambda 函数，不过是容器类型的 Lambda 函数。
基本上可以运行完整的容器。
对。数据库领域还有三项创新。第一项是我们去年谈过的 OrioleDB。过去一年我们对它做了全面测试，确保它足够稳固，可以进入 Postgres 生态。这三项创新分别涉及性能、纵向扩展和横向扩展。OrioleDB 解决性能问题，它可以直接替换 Postgres 目前使用的堆式存储引擎，速度大约快 1.5 到 2 倍，而且你不需要……
OrioleDB 与 Multigres
……不用改动其他东西，完全兼容。它彻底免去了某些后台任务，比如 vacuum，因此数据库运行效率也很高。今年我们的主要工作，是用 PG regress 做全面的 Postgres 兼容性测试，也经过了 Antithesis 测试。我们每晚跑 TPC-C 基准和 JSON 测试，确保它几乎不可能丢数据。明天我们会发布完整 Beta 版，并采用 Apache 2.0 许可证。许可证包含专利授权，所以我们收购了这项技术、继续开发、买下专利，现在把它免费开放出来。
你刚才提到一件让我一直很在意的事：你们测试了每一种 Operator，然后说每一种都会在某些情况下丢数据。
这是第二项，也就是扩展能力。
那就是 Multigres。
对，Multigres 是第二项重大发布。我们审视了 Postgres 生态。不了解 Operator 的听众可以这样理解：运行 Postgres 时，你从单节点开始，但和几乎所有数据库一样，之后你会想运行多个节点，并需要故障切换、备份管理等功能。通常会用一个 Operator 来管理整个集群。Postgres 生态里有好几个 Operator，我们发现它们在某些情况下都可能丢数据。因此我们决定从头重写 Operator 的整个架构。
Multigres 最初是为了给 Postgres 社区带来分片能力，但最后发展成一整套操作系统。我们又对它做了非常严格的测试：连续进行了 1,000 次故障切换，没有丢失任何数据；还用各种能想到的方式折腾它，确认它是否会丢数据。现在我们对它的稳定性很有信心，明天也会发布。它是完全开源的；客户可以通过邀请制在我们的平台上使用。运行重要工作负载的用户可以联系我们，我们会开始帮他们扩展。
Multigres 现在是否已经完整实现了和 Vitess 平行的全部能力，还是还有东西没做完？
实际上，这件事挺有意思。Sugu 最初为 MySQL 生态创建了 Vitess，专门解决分片问题。他加入后说，当前的首要目标应该是兼容性，因为过去用 Vitess 时，为了分片总得修改一些查询。于是他说，他只想先专注于兼容性。我们的从头重写就是按这个目标设计的：等发布分片功能时，数据库不需要任何改动，你仍然运行同样的查询，Multigres 会处理好，一行代码都不用改。
这个愿景太棒了，而且你们两年就做到了。
是一年。我们还没发布分片。我看过早期原型和设计方案，预计部分功能明年年初推出，具体取决于平台上正在推进的其他事情。我们手头工作很多，但对进度很满意，也很有信心。
我觉得这是 Postgres 实现全面主导的最后一块拼图。
是的。
不熟悉的人可以去查查 YouTube、GitHub 等服务背后的技术栈。如果工作负载将来从 MySQL 转向 Postgres，就需要这套东西，Supabase 才能赢。
希望它不只是为了……
多方参与的 Postgres 扩展
希望它不只是 Supabase 客户能用，对吧？它是完全开源、面向社区的项目。任何在大规模运行 Postgres 的人都应该能用 Multigres。
对。我相信所有和 Postgres 有关的组织、公司都会参与贡献，因为大家都希望它成功。
是啊。
我们有一个完整的设计伙伴计划，正在和 Booz Allen、Postman、Perplexity 等公司合作。很多客户正在加入，他们需要这套东西来帮助自己扩展大规模运行的 Postgres。
第三项也很重要，是横向扩展。目前我们每个月都会在平台上新建大约 500 万个数据库。我们展望的未来是……
纵向扩展、横向扩展与 Turso
我们认为，未来每个月可能要新建数十亿个数据库。横向扩展是完全不同的问题，所以我们必须研究新的架构和这个领域的团队。在面向智能体的数据库领域，没有哪家领先厂商比 Turso 做得更好。因此我们明天会宣布收购 Turso，帮助我们驱动面向智能体的数据库。
这太棒了。Turso 主要基于 SQLite，不过这并不重要，关键是它的架构——我想说的是广播？这就是横向扩展的思路吗？它们扩展 SQLite 的办法是一个写入者、多个读取者。
对。SQLite 本身只有一个写入者，它是一种文件格式，通常……
他们把这个叫作 MVCC。
没错。他们在 SQLite 上构建了 Turso 架构，实现 MVCC，这样就可以有多个写入者。
SQLite 的许可证有点特殊，所以他们得维护一个分支。
他们最初从 libSQL 起步，后来做出了另一套很酷的架构。几周前人们还在讨论它运行在 S3 上。数据库领域的一些创新其实来自对象存储的进展。对象存储新增了不少功能，现在可以在某种程度上像数据库一样使用。对象存储的数据持久性大概是“11 个 9”，这说的是持久性，不是可靠性，不过……
对，不是可靠性。
它能提供数据库集群通常需要的底层能力。因此有些很有意思的数据库和数据用例直接构建在对象存储之上。但它也有局限。按我们的判断，它更适合较小的用例。事务型数据库要做很多读写，所以不适合用这种方式承载超大规模事务；这也是我们开发 Multigres 的原因。但面对数十亿个数据库的目标，我们需要的是一种文件格式，而 SQLite 特别有意思，也正变得越来越主流。
真正引起我们兴趣的是 Turso。我们联系了创始人 Glauber；他发布了一篇文章，介绍他们如何重写系统，这让我们看到了实现 Postgres 兼容、同时沿用他们文件格式的路径。所以我们要收购他们，并保留 Turso 品牌：Turso 会专注于 SQLite。我们还会在 Supabase 推出一种更小的实例类型 Supabase Spark，它兼容我们的所有库。你可以先为任何想法或原型启动一个数据库；如果项目做起来了，再升级到完整的 Postgres 数据库，直至 Multigres。
我知道你们为此努力很久了。这就是你们一直想实现的愿景，对吧？
对，如何向上扩展、再向下缩小，一直是我们在研究的问题。后来出现了一些新技术，我们才意识到这件事可以做到。
你们现在每个月新建 500 万个数据库，照这个趋势以后可能是每月数十亿个。其中一个诀窍是，这些数据库其实很小。
对，它们很小，是 vibe coding 应用。
我不知道你们对这类应用有什么观察。
它们得先获得用户 traction。比如登上 Hacker News 首页后，你得确保自己可以继续扩展很多倍。
平滑迁移与非技术型创业者
我们做这些事情的整体目标，是确保后端之间有非常顺畅的迁移路径，能够做到零停机迁移。这是必需的。我们看到，越来越多非技术背景的创业者在打造整家公司。我们的客户 MagicSchool 就是一个例子：创始人原本是教师，他看到了教学中的低效之处，比如教师把时间花在本来可以自动化的任务上。现在出现了一批创业公司，从一开始就没有技术联合创始人，也没有 CTO；这已经不再是孤例，而是越来越普遍的现象。
现在人人都是建设者。
是啊。这也是过去 18 个月里增长如此惊人的原因。不过这一切仍然像是刚刚开始，我觉得市场规模还会大得多，几乎像是面向消费者的……
开发者营销与梗图
……像建设者一样的人：公司里的员工，以及想创办自己公司的那些人。这会意味着更多数据库。
就像我们刚才说的（笑），如果每个人都有一套专属 Postgres 集群，我们很快就会把全世界的实体计算机用光；现在基本就是这么回事。
我们今年已经遇到这个问题了。增长太快，计算容量成了我们必须处理的问题。
祝贺你们。我还注意到，Glauber 也是梗图高手。
那确实是我该做的事之一（笑）。
是啊，他真厉害。Rubberbase 梗图背后的人，表面低调，实际上很有杀伤力。
我还要说 Will Glauber 也是。
没错，非常厉害。
你们会互相交流什么东西好笑吗？
我们肯定会让他使用 Supabase 的 Twitter 账号。我确实需要帮手。
等等，现在还是你在运营吗？
现在有一小组青少年帮我（笑）。
你们还办工作坊，对吧？
对，我们每周办一次梗图工作坊。不过这类工作很难招人：做这种营销既要懂技术，也要知道开发者觉得什么好笑。
其实你也是个梗图高手。
我没你那么好笑。你真的很会做。有一张海鸥的图，你像是站在……
Supabase 的海龟站在 Postgres 上？我记得是只海鸥。
是只站着的海鸥，骑在一只飞着的海鸥上。
天啊，我现在找不到那张图。这都是 Supabase 的深层历史了。当时那些梗图实在太好，大家都想学你，却学不来；那就是你们的护城河（笑）——梗图。
有些大公司也试图在 Twitter 账号上做梗图，我就不点名了（笑）。但这确实很难，正如我说的，很难招到合适的人。
有人写过一篇四万字的长文，分析你们的梗图策略。
早期确实有人研究了我们的 Twitter 策略，还发到了 Hacker News。
对，发在 Hacker News 上。好笑的是，那人把我们的策略写了下来，而我们自己当时还没把它整理成文档。后来新营销人员入职，我们就直接把别人写的策略交给他们（笑）。
当然，Hacker News 上有人不喜欢那篇文章，还在评论里批评作者。
对，有篇叫《Supabase 信息流运营四个月的经验》的文章，他只是观察了你们的做法。
是 2022 年吗？我记得我提到过。哦，原来是你。后来 Ant 把那篇文章的照片拍下来，发到了我们的 Twitter 账号上（笑）。
“你们越讨厌我，我越有动力。”这是什么有意思的文章？我还评论了（笑）。
我们早期很多增长都要感谢 Hacker News。那时候我得一直守着它。
那得聊聊，你和 Dang 做了什么交易，才……
Dani 已经因为我们一周发布太多东西，训过我们很多次了（笑）。他对 Hacker News 和 YC 之间的关联确实很谨慎。出了什么事，他就会把我们推出来，好让大家知道：“我们不是专门为 YC 的客户做事，我们是独立网站。”他一直在帮忙确保我们不会损害 Hacker News 的名声。
到现在你们已经不需要他们了，不过 Dang 肯定……
Hacker News 与早期发布策略
Dang 的信誉非常高。不过我确实觉得，你们搞“发布周”的策略很厉害。我记得有一周里四五个发布项目全都冲到 Hacker News 首页，甚至排第一。
我为此被狠狠批评过，因为我当时还得意地发了推文：“看，我们做到了。”后来有人训我，说这看起来不太好：一家 YC 公司突然占据 Hacker News 首页，会显得有偏袒。
我还把你们上首页这件事大肆宣扬。想给大家提个醒：千万别把自己登上 Hacker News 首页的截图发到 Twitter 上。那确实会显得……老实说，就是在炫耀。这个批评有道理。
这些事现在算是很久以前了，毕竟已经过去几年。不过不了解 Supabase 历史的人，还是可以把它们当作一段必看的发展历程。
还有什么？我觉得最靠前的那篇帖子挺有意思。
这是发布帖。
对，不过当时是别人替我们发布的。我们还没准备好在 Hacker News 上发布。
而且你们当时也没把自己定位成 Firebase 替代品。
对，那天我们才改了标语。原来的标语是……
从发布到迁移
……原来的标语。
是“实时 Postgres”。事情是这样的：我们想做一家 Postgres 公司，但我上一家公司需要从 Firebase 迁移到 Postgres，又需要实时功能，所以我就在 Postgres 上搭了一个实时引擎。我们以为这就是杀手级功能，因为它在开源社区开始受到关注。于是我们用了“实时 Postgres”这个说法，结果没人关心。网站上线后也没人关心。于是我们改成“开源 Firebase 替代品”，因为我当初换平台就是这个原因。大概只过了 12 个小时，那篇帖子就发布了。
那篇现在还是 Hacker News 历史热门榜第一。
当时我们部署在 DigitalOcean，每个新数据库都要两个 Droplet，每个每月 5 美元，一个跑数据库，另一个跑 API。我们想把 API 升级，但那时只有少数几个测试用户。突然之间……
我记得我们当时只有 8 个用户；那次发布直接把人数从 8 个拉到了 800 个。
然后我们在 48 小时内就用完了大约 1 万美元的 DigitalOcean 额度。那时我们刚进 YC，AWS 说：“如果你们迁过来，我们可以给你们大约 15 万美元额度。”所以我们在 YC 的第一周，就把 800 个数据库迁到了另一朵云上。迁一个数据库已经够痛苦了，迁 800 个绝不是你想在 YC 第一周做的事（笑）。
你还记得吗？我们本来可以继续用 DigitalOcean。进 YC 后，他们当时给的 DigitalOcean 额度很高。我们去问能不能拿，因为业务正快速增长，他们说：“不行，你们已经用过 1 万美元的额度，不能再给你们 30 万美元的那一档。”所以我们只好迁到 AWS（笑）。这成了 DigitalOcean 错失的一大机会。我们现在给 AWS 的账单，可能让他们失去了一个本来会成为大客户的机会，就是因为当时规则太死板。
那时候正值疫情，所有人都担心接下来会发生什么。我想他们是不想承担过多风险。
对，这也情有可原。
是啊，就当时的局势而言，他们那样做完全可以理解。
疫情期间大家做过不少不理性的决定。谁知道呢？我本来还想说，你们现在可能比 DigitalOcean 更值钱了，不过 DigitalOcean 最近也势头很猛。
看看这个。
因为计算机硬件去年涨了三倍。
哇，真不错。他们现在估值多少？160 亿？
现在是 160 亿美元。
16 billion，没错。
看来 CPU 也短缺了。
是，供应短缺。
你们受影响如何？我们一直在和 AWS 讨论，反复碰到容量上限。需求突然暴涨时，有办法应对吗？还是只能和云厂商签好协议？
我们必须非常仔细地规划，也得付更多钱、和他们建立合作关系。明天我们还会宣布引入新的投资伙伴 Capital G。Capital G 能接入 Alphabet 生态，对我们各方面都有帮助。我们现在必须考虑多云战略。
我们需要 GCP。
确实。我们需要更多计算资源，所以 GCP 是很自然的选择。当然，我们也希望尽可能和所有 AI 实验室合作。他们有一系列产品，我们已经在 Gemini 上与他们合作，也希望深入嵌入他们的产品。这也关联到你刚才说的：数据库生态正受到块存储及其他创新的影响。显然 AWS 在这方面领先。
如果把 GCS 当作 S3 的替代品，多云就很难做。
对象存储、变现速度与 AI 浪潮
对，只要它们具备那些功能就行。其实我不确定他们的对象存储是不是都有这些功能，不过 S3 有什么，其他服务通常也会跟上。
我记得大概三年前，他们推出了强一致性。
对，这就是帮助很大的创新。
而且他们免费推出，直接上线给所有人用，真让人惊讶。
还有 S3 Express，这也是很大的改变。
为什么？
典型做法是先写到本地磁盘，再批量写到更耐久的存储。批处理写入需要 1 到 2 毫秒。要向客户端确认写入完成，你必须先把数据批量写到足够耐久的地方。S3 Express 的持久性比不上 S3，不是“11 个 9”，但已经够用了。
可以说是“短暂但耐久”。
没错。你可以先把它当作缓存，在后台再迁移到 S3。
那还需要 Redis 吗？
需要，S3 Express 还远不够快。缓存层基本是内存、NVMe 硬盘、本地直连存储、S3 Express，然后才是 S3。
好，数据量有点大，我们刚才跳来跳去。还有几个问题。你们的口号以前是“周末构建，扩展到百万用户”，现在变成了“从原型到 PB 级”，这反映了你们扩展规模的变化。你们能讲讲早期 Supabase 和现在的差别吗？用户开始一个项目后，扩张速度有多快？
最大的变化是用户变现的速度。
是啊。
以前你先选数据库、开发产品，之后某个阶段再接入账单系统。现在你可以在智能体层直接接入 Stripe。我们看到用户启动项目后，同一周内就开始赚到可观收入。
在 vibe coding 初期，我们还不确定它会不会长久，也没意识到它会改变软件开发方式。但一看到有人在产品发布后的头几天就赚了大约 1 万美元，我们就觉得：“哇，这是真的。”
人们做出来的产品确实能创造真实收入，所以我们知道必须投入。过去也遇到过成功浪潮，比如 NFT 很火时，我们加了一些功能，支持用 Ethereum 和 Solana 登录；但大家都觉得那股热潮迟早会过去，所以没有投入大量开发时间。对 vibe coding，我们团队认真讨论了到底要投入多少。那时最大的客户已快碰到现有能力的上限，所以我们知道必须两头兼顾：既要为小型原型创新，也要在更大规模上创新。这就需要更多人手。
从数据看，Supabase 经历了三个 AI 阶段。第一阶段是嵌入，我想我们当时推出了……
Supabase Vector——我现在已经把它转成文字了（笑），以后都会这样。我可能得更新一下这段介绍。
对，你以前好像只讲过那一次……
向量、增长与 AI 推荐
对，你唯一一次在……
我们确实做过那场演讲。当时各种嵌入数据库、向量数据库不断出现，我们就强调 Postgres 可以用作向量数据库。Andrew Kane 是完全独立的开发者，他做了一个很棒的扩展。我们想让市场知道 Postgres 几乎什么都能做；如果只是存嵌入向量，你不一定需要另一种数据库。这是第一阶段，对我们的增长很有帮助，也让 Postgres 生态受益。现在嵌入领域还有很多创新，比如 Turbopuffer 正在做的东西，借鉴了 Turso 的不少创新，我觉得这类技术有很出色的用途。
第二阶段是 vibe coding 浪潮，Lovable、Bolt 等工具开始兴起，大约在 2024 年底。那时我们认真讨论要不要加入这个市场，要不要为这些工具提供服务，甚至要不要在 Supabase 上打造自己的 vibe coding 平台。最终我们的使命是存储全世界的数据。按我们的口号，我们要在人们刚开始时就在场，并让他们之后不想离开。大家确实从一些小玩具项目起步，但这仍然符合我们的使命；我们只需要相信这些工具会不断变好。
第三阶段是今年开始的，数据增长变得惊人，因为模型本身变强了。我们的漏斗顶端和注册率开始迅速上升。通常这种增长来自投入大量营销费用，但我们几乎没花钱做营销。
大部分其实就是梗图之类的东西。我这里有一张你们的图表。看起来都差不多，不过是因为规模在指数增长，所以你得不断调整图表（笑）。
另一个惊人的地方是，流量和漏斗顶部变得更偏消费用户时，激活率和付费转化率通常会下降，但我们的这两项指标都上升了，而且升得很快。
你们怎么知道激活和付费转化率？是看自己的数据吗？
对，我们看完整的内部指标。原因是用户从注册到激活的过程由智能体替他们完成。
一步就完成了，所以激活率几乎是 100%。
这些用户的付费转化率也高于传统开发者用户。
太好了。其他开发者工具应该也都看到类似情况吧？
只是增幅不同。我觉得你们显然是领先者之一。我本来想展示一张图。我有个 AEO 追踪器，搜索 Supabase 时，有几个类别你们排名第一。各个前沿模型都把你们推荐为首选的一体化后端。一体化后端指你们原有的产品组合：身份验证、函数、数据库、API 等。挺有意思的是，你们在大语言模型兴起前三四年就已经进入市场，又正好把自己打造为当时主流技术的领先竞争者。
对。
这样你们就能接棒了。
我们的时机确实非常好，简直无法更巧，但完全是偶然。我觉得这也和第一性原理有关。我们采访过一些 LLM 兴起之后才创业的创始人，比如 Resend。我们也问过他们，为什么 LLM 总推荐 Resend？原因是他们在 AEO 上做了很多正确的事。
没错，我们也在这方面投入很多。但我们从一开始就已经在这个位置上了，这只是碰巧。现在我们要做的是保持领先，并继续经营好社区。我们其中一个……
社区共建与众筹
我们早期的增长策略之一，就是花很多时间和社区交流。后来社区成员会写博客、拍 YouTube 视频、做播客，讲 Supabase 在不同场景下怎么用，以及“我是怎么做出这个东西的”。我相信这些内容都被模型大量吸收了。
开源当然也有帮助。社区方面你们还有个有意思的宣布：公司融资不少，也想让社区更深入地参与。
去年 Supabase Select 上，我们宣布要做一轮众筹。这一直是我们想做的事，本来应该更早启动，只是一直有很多别的事情要忙。之后一年，我们都在和律师沟通。律师说，按我们希望参与的人数，目前没有办法让他们参与，除非每个人都是合格投资者。我们就问：“如果他们不投资呢？如果我们直接把股票送给他们呢？”他们研究后告诉我们，如果真的只是送股票，法律上有一种可行机制。于是我们预留了大约 100 万美元的 Supabase 股票，准备送给许多社区成员。我们会先在台上公布第一位成员：Supabase Discord 里的 Gary Austin。
他是 Supabase 社区的传奇人物。我们查了一下数据：过去六年里，Gary 在 Supabase Discord 上回答了 20,000 个问题，其中 13,000 个是在提问后的第一小时内回答的。
他又不是 Grok 机器人，是真人（笑）。
你见过他吗？他是什么样的人？
见过，他是真人。他基本上已经退休了，只是对 Supabase 感兴趣。
他叫 Gary Austin？还是 Gary Abbott？
Gary Abbott 才是他的真名。
就是这位（笑）。
他很喜欢 Supabase，还自己做了一个类似的应用，因为他喜欢红酒。
嗯。
他还挺享受这些事，比如圣诞树上挂着 Supabase 标志（笑）。
顺带一提，这些是我最喜欢的 Supabase 梗图。你这是在提醒我，我的 Supabase 快用完了。
这就是我们要宣布的事情：现在可以奖励那些在 Supabase 生态里作出杰出贡献的人。
Discord 现在依然是很强的社区渠道吗？我对 Discord 有点矛盾：它聊天体验最好，Slack 又很糟；但 Discord 内容不是公开的，里面的劳动成果也就很难规模化传播。
是啊。
你们找到什么办法解决了吗？
早期我们看过一些工具，但最后没用，因为你仍然得判断哪些内容适合公开、哪些不适合。我们当时花了很多时间争论应该在哪里经营社区：Discord、Slack，还是 Reddit？我们试过几种方案，最后决定大家在哪儿，就去哪儿：Discord 用户会用 Discord，Reddit 用户会用 Reddit。基本上我们得把社区运营做到所有这些地方。答案就是“去用户所在的地方”，但工作量很大。
不过效果不错，对吧？这是正确的选择。
后来有很多很棒的工具出现。
我觉得还没有哪个工具真正经受住时间考验，但确实有人把 Discord 讨论同步成公开问答网站。
我不知道这对谁真正有效过。
还有 Common Room 之类的。
我们只做过一件内部工具：有人在任何一个渠道问了正当问题，我们就把问题和回答抓取进……
社区知识与企业产品
……我们自己的网站。其实我们把内容抓到 GitHub Discussions，再同步到网站上。这样这些内容就能被找到。
你们把 GitHub 当成 CMS 用。
对，确实是 CMS。这个策略很好，因为大家反复问的都是同一批问题，我们就把答案整理出来。也会让人困惑：有 Supabase 开源项目，也有 Supabase 云平台，而大多数人来支持的应该是云平台。
你们知道自己的开源市场覆盖率大概是多少吗？这个数据很难估。
我们有意不去追踪。开源版本里没有埋点，大家可以自由使用。有大型企业，比如制药公司，会来找我们说：“我们运行着你们开源项目的 100 个实例，能不能提供一款产品？”因此我们有一款叫 Control Tower 的产品，帮助企业监控一组数据库。你在我们网站上找不到它。
哎，得了吧（笑）。为什么不放上去？
因为明天才发布（笑）。
我还不知道它是不是明天发布。
总之，Control Tower 提供的是数据库集群视图。我们有一款很受欢迎的 Supabase for Platforms，很多 AI 公司都基于它构建；我们为他们创建了数百万个数据库。我们只需要把现有能力重新包装给企业。企业也想为自己的用户启动许多内部 Supabase 实例，并能查看和管理它们。因此 Control Tower 本质上是把我们已经为平台服务商开发的能力，重新打包成面向单个企业的产品。
我想聊聊企业业务，因为很多人认为你们主要靠自下而上的 GTM。我先夸一下……
我觉得我们最近最成功的一次发布，是 Supabase for Platforms。
这个产品是……
对，是 2025 年 12 月。
我看到一些数据，或者你们称它成功；我不太确定。企业业务到底是什么故事？除了“给我一个仪表盘”之外，还有什么？
首先得谈谈销售策略。
好。
Supabase 是一家很典型的 PLG 公司。我们喜欢产品驱动增长，YC 每期大约 60% 的创业公司都在用……
产品驱动销售与企业增长
……Supabase。我们几乎把所有精力都用在成为一家“索引型公司”上。我们的榜样是 Stripe，希望追随他们的脚步。在我们见过的开发者工具公司里，Stripe 是少数经受住市场十多年变化、仍然保有开发者喜爱的公司之一。
我们开始做销售后，首先叠加了一层我们称为“产品销售”的做法。我们关注产品触发信号：客户可能是一个重要品牌，也可能是业务正在扩张、碰到了某些限制、遇到了错误，或者开始支付一定金额。我们有很多这样的信号。后来 AI 出现了，我们意识到可以利用这些数据做有意思的事情。
比如每周有 1,000 个产品触发信号。我们给遇到问题的客户发 1,000 封邮件，假设 500 人回复。对于没回复的那组，我们设为对照组，测得他们每月自然增长 25%。然后让销售团队联系回复的客户，唯一目标就是和他们通话并提供帮助。我们掌握他们的流量模式，可以让 AI 帮忙了解具体问题，再给销售人员一份沟通提纲。结果，只要打电话帮到客户，他们的账户就会增长 125%。这多出来的 100% 增量，就是我们用来计算销售人员报酬的部分。
传统做法是让销售人员打电话卖东西，然后把全部业绩都算给他们。但我们知道这组客户的数据库和平台本来每月会增长 25%，所以能确定销售团队带来了额外的 100% 增长。这就是我们的销售方式：始终聚焦重要客户，或某个明确的产品需求。
企业客户通常是为了启动很多数据库而来，几乎不会把生产数据库迁过来。比如从 MySQL 迁到 Postgres，或从一种可扩展数据库迁到另一种，几乎不会发生。这是 Supabase 创立时的核心判断。我们研究过的那些 Postgres 或数据库公司，只要把迁移当作主要策略，最后都失败了。你根本无法说服人们迁移。即使你做出更大、更好、更可扩展的 Postgres，也得在客户第一天开始时就进入，并一直让他们留下来，直到第 1,000 天、第 10,000 天。
因此，我们的重点是从第一天就赢得企业客户。
也就是全新项目（greenfield）。
对，是全新项目；他们仍然不会迁移现有系统。
我敢说他们几乎从来不会迁移。
有一类客户确实会需要 Multigres。我们和一些大型企业聊过，他们在考虑使用开源版本，也希望参与指导开发，因为他们遇到了 Postgres 大规模运行的问题。但未来五年左右，我们的企业业务几乎都会聚焦于全新项目。事实证明，这在企业里是非常常见的需求，因为他们希望产品团队尽可能多地开发和创新。对我们来说时机正好，因为我们长期以来都在专注这类场景。
Control Tower 是我们最重要的产品之一。Multigres 则给了我们机会：如果大型客户以后想迁移工作负载，我们就能接住。但至少未来五年，这不会是我们的核心重点。我们必须专注于先进入企业，再逐步扩大合作规模。另外一项变化是，我们过去显然把所有精力都放在……
C 级高管成为内部倡导者
过去，我们把产品卖给开发者，让他们成为内部倡导者，帮我们在公司里推广。现在有些 CPO 会说：“我十年没写代码了，但现在因为 Lovable 和 Supabase，我正在公司内部做各种东西。”所以我们现在有 C 级高管成为倡导者，不需要专门铺一套庞大的销售流程。
很棒。提到 Lovable、Bolt，Lovable 也要做自己的数据库。大家都会尝试进入彼此的地盘，这很正常。哪一边的用户黏性更强？
哪个更黏？
比如 CPO 更可能依赖 Lovable，还是依赖 Supabase？你们会考虑这个问题吗？
这个问题很好。我觉得运营数据库终归很难。
有道理。而且就像我们刚才说的，迁移数据库比迁移前端工具更难。
我不是说 Lovable 不黏——我觉得它很出色。实际上，他们是最早把智能体和数据库结合得很好的团队之一，确保智能体不会对数据库乱来。早期智能体会试图把图像数据塞进 Postgres，还会关掉 RLS 才能让项目跑起来，简直像用回形针硬凑。Lovable 写了很好的 Skills，阻止智能体做这些蠢事。他们是第一批做到这一点的。
这就是他们的秘诀。
对，就是解决这些问题。现在模型本身也不会再做那么多蠢事了。
是的，情况改善了很多。从 2022 年 Will Smith 吃意大利面的效果，到 2026 年 Will Smith 吃意大利面的效果，差别太大了。
对，那是个著名梗图。
说到迁移，我先不展开。一个让我恍然大悟的观点来自你们的董事会成员、Coatue 的 Karen。她认为，你们不只是替代 Firebase，也可能成为亚马逊 RDS 的新选择。如果 Supabase 在 AI 之后进入第四阶段，那也许能带来又一个万倍增长：把 Oracle 拔掉。我听过一个很夸张的数据，大约一年前有人说，按收入计算只有 5% 的 Oracle 工作负载运行在云端。很多人都说要替换 Oracle、做数据库迁移；不过 Oracle 也在努力把东西迁到云上。
我研究过过去尝试这种策略的数据库厂商。听起来很棒，我们当然也会尝试，为什么不试呢？但这非常困难。我觉得第一步还是先进入企业。
这很合理。我每天都和编码智能体团队交流，他们寄予厚望的一点就是终于能迁离这些旧软件，最好把整个系统都切换掉。
确实。Oracle 之所以黏性这么强，一个原因是大家在里面写了数百万行存储过程，把所有逻辑都塞进数据库。如今重写它们可能容易多了。
对。编码智能体可能就是那个转折点。它们也许还没完全成熟；也许你们还需要更支持本地部署。迁移的问题其实不全在重写代码上。比如，你们可以做迁移……
在线迁移与分析型数据库
分析数据通常可以比较轻松地从一个数据仓库迁到另一个。问题在于，OLTP 数据库通常支撑着最赚钱的应用。停机一分钟就会造成收入损失。所以你不得不让两套系统并行运行，风险是出现“脑裂”：一部分数据在一边，另一部分在另一边。试过协调脑裂数据的人都知道这很难。因此 OLTP 的迁移风险太高，很多时候大家会先拆分工作负载，启动新的操作，再希望慢慢把东西迁过去。
对，最后通常会多出两个问题（笑）。说到 OLTP，这有点像数据库爱好者的偏门话题。我们之前也请过 Databricks 的两位联合创始人 Matei 和 Reynold，他们声称已经解决了 HTAP。
嗯。
这可以说是数据库人的圣杯。传统上你需要 OLTP 数据库和 OLAP 数据库，两者互不相干；但有时大家希望不用再复制数据。你们有关注这个方向吗？Supabase 以后会做吗？
有，我们特别关注 DuckLake。我觉得 DuckLake 和 DuckDB 都是很有意思的技术。
MotherDuck，像数据湖一样的 DuckLake？它到底是什么？
DuckDB 最近很受关注，可以说是分析场景里的 SQLite。
采用列式存储。
对。它可以直接读取对象存储，也能读取 Postgres 数据库。它是很棒的开源技术。还有 DuckDB Labs 最近被 AWS 收购了。负责开发的基金会正在围绕开源项目建立社区。我觉得 DuckDB 有点像分析生态里的 Postgres：它努力保持独立，不被某一家拥有，功能很多，也很灵活。
就像创始人是位荷兰教授。
对，他们在荷兰生活和工作，很不错。我们对数据仓库的兴趣，不是想把 Postgres 变成分析数据库，而是想让不同工作用合适的技术。我不知道有多少人真的解决了 HTAP 这道难题，对象存储也许是一个方案。但一般来说，OLTP 到了某个规模后就需要分片。NVMe 磁盘容量有限。如果事务必须跨两台服务器拆分，最终就得从对象存储读取数据，这会拖慢数据库。因此我们认为，分片是把 OLTP 扩展到 PB 级的最佳方式，分析则应该另行处理。
这不意味着你不该把数据直接存进对象存储，再从其他路径读取；只是把 OLTP 和分析强行合并，未必有意义。
好，那先聊到这里。我们还有其他内容要处理。我觉得 Databricks 有些创新是利用数据库机器上的闲置计算资源来做复制，这是我对他们方案的理解。
老实说，我还没仔细研究他们如何做 HTAP，所以可能理解错了。
对，你们专注在自己的领域，客户也没有天天敲桌子要求这个。但如果你们想有一天成为首屈一指的数据库公司，就得对此有所回应。
对（笑）。
持久化工作流与模型合作
是啊。另一个我想问的是持久化工作流这块。你知道我一直在为 Temporal 摇旗呐喊。你们每年都做一点相关事情。
对，我们在逐步推进（笑）。
为什么它对你们不是更高优先级？Temporal 发展得很好。要做持久化工作流，你们缺的是什么？计算能力？
现在已经在做了。
对，那你们正在做。
这是个很有意思的领域。社区有人试着在 Supabase Functions 上搭工作流引擎，但因为 2 秒超时限制，行不通。
现在你们有了基础能力，可以支持长时间运行的持久化工作流。
对。
我对 Supabase 最初的设想是：它应该是一朵一体化、面向智能体的云，是大家都能使用的集成式后端。现在用 ChatGPT 登录也是很好的功能。你得把 AI 想要的一切都给它，它就会成为你的好朋友。
基本就是这样（笑）。我们面向 B2B 的策略，是尽可能多地和前沿实验室、模型合作。我们得广泛适配。与此同时，我们看到产品附加率也在提高。
美国这些实验室你们当然会合作，你们也在美国。其他实验室有重要合作吗？比如 Mistral、Cohere、中国的实验室？
目前不太多，不过他们也许会做。
所以你们主要关注美国市场？
主要是因为目前带来最多流量的是美国实验室，情况以后也可能变化。
合作具体是什么样的？出现在他们的应用商店是一回事，成为他们推出产品时默认使用的后端又是另一回事。
我们很希望成为这类服务商。过去做不到的原因之一，是我们接不住他们的规模。比如 ChatGPT 现在有多少用户？每月 10 亿，还是 12 亿月活？假设每个用户每个月启动一个数据库，我们就得启动 12 亿个 Postgres 服务。正如我前面说的，我们必须做到每月数十亿个数据库。直到今天收购这家公司、获得能推动扩展的技术后，我们才有可能做到。
扩大规模。那除此之外，未来一年公司的其他最高优先级是什么？你们怎么确定方向？
最高优先级是赢得战略实验室和模型的合作，并继续推动 PLG；企业业务则聚焦赢得新项目。
更准确地说，是 PLG 的上限变了。公司刚成立时，我们觉得 PLG 大概能做到 1 亿美元，或许 2 亿美元，然后就得换一种增长方式。但 AI 抬高了这个上限，我们还不知道能到哪里：10 亿、20 亿，还是可以继续增长？与此同时，其他业务也得做。去年我们决定两头都做：小项目和大项目都要做。也许我们有点贪心（笑）。
我觉得这正是用户想要的。用户会付钱让你们处理细节，把规模一步步提升几个数量级。
我不知道具体是几个数量级，但肯定很多。更疯狂的是，18 个月前我们已经增长很快了。如果有人问我怎么把漏斗顶部扩大十倍，我会说“没办法，这太疯狂了”。然后整个市场突然……
增长目标与开发方式
……突然爆发了。接下来看看会怎样。
记得年初公司团建时，我们定了一个非常大胆的收入目标。有人来跟我说：“你不该定这个目标，团队肯定完不成，会很失望。”结果我们只用了大约四个月就达到了目标。从今年年初开始，增长曲线就非常夸张。
太棒了。你们还有哪些悬而未决的问题？如果你有水晶球，知道答案后会改变你下注方向的那种问题？
我最常思考的是两件事：未来的软件开发会如何进行，以及人们会开发什么。
可能的答案是什么？只是会有更多智能体吗？
今年我们重点关注这个问题。我会在主题演讲里讲到：我们正在从仪表盘公司转型。最初我们的最佳开发者体验，是通过仪表盘操作。后来大家谈无头模式，我们一开始就支持无头模式，也有 Headless 360、Salesforce 等各种类似的东西……
让本地开发适配智能体
Supabase 从一开始就由 API 驱动，这也是我们今年成功的原因之一。今年我们重点转向代码优先、原生的开发体验。启动一个 Supabase 本地实例时，会得到一个 `supabase` 文件夹，它代表你的数据库，包含所有函数和其他内容。
现在就有这个功能吗？
有，使用我们的 CLI 就行。
所以它是个虚拟文件系统？
更准确地说，它是基础设施即代码的一种表示。
明白。
明天我们要宣布声明式 Schema 的最后一项改动。这很有挑战，因为必须覆盖整个 Postgres。现在你可以在文件夹里用一组文件声明式地描述整个 Postgres 数据库的结构。这对智能体很重要。以往使用 Postgres 时，每次改动都要往 migrations 文件夹加一个迁移文件，作为历史记录。这是行业标准，但如果让智能体去读一千个文件，再问它某张表是什么结构，它只能从那一千个文件里猜。或者你得在本地启动数据库、运行所有迁移，再查看数据库结构，那太慢了。
我们要把 `supabase` 文件夹里的 `schemas` 目录变成数据库的完整声明式状态。表、策略、数据库注释等内容都会放进这些文件。我们正在发布一个新库 PG Delta，任何 Postgres 数据库都能用；同时也为 Supabase 提供了专门机制。这是面向智能体的重要一步。智能体主要通过代码工作，不想去连接别的系统；它们需要在文件系统里快速迭代。
现在大家用 CLI 和各种开发 Harness，感觉都不错。我猜未来会进一步变化。比如我现在能直接用手机做一些开发，因为我知道背后的运行方式，能告诉它要从基础设施角度做什么。但未来我可以想象：你不必是工程师，只要有个想法，对手机、Dot 或你的个人智能体说“我想做 X”，一秒钟后应用就上线了，你还能自己继续迭代。
我一直在思考这种情况下人们会需要什么用例：它会不会是个性化的？我们应当关注什么？这些应用能扩展吗？需要什么机制、开发流程和工具，才能确保我们成为这个新世界的默认服务商？
你有什么问题想用水晶球提前知道答案吗？
我当软件工程师已经几十年了，对软件应该怎么构建有很多看法，比如持续集成、持续交付。我发现自己会把这些意见强加给智能体，告诉它“应该这样做”。但现在越来越多时候其实没必要这么做。我担心的是：它们会不会都收敛到同一种软件开发方式？
对，就是模式坍塌。那倒不错，大家都会用 Supabase（笑）。但软件开发行业很有意思的一点，就是大家会为哪种方法才正确而激烈争论。我们会失去这些争论吗？
我们当然希望想法多样，这样最好的方案才能胜出。但模型会不会让所有人都变得太懒，连细节都懒得看？
开发者多样性与创始人合作
那它们就会全都收敛到同一种软件开发方式。这会不会让大家停在一个局部最优上？
我不知道。我觉得这确实是个合理的担忧，但也不是你能控制的。经验较少、随意搭应用的人，可能会收敛到模型给出的主流做法——也就是你们提供的方式。但有判断力、技能高超的人，依然会关注细节。
对，然后他们的做法会逐渐影响其他人。
这是我的想法。
这些高技能人才还会继续被培养出来吗？
不知道。我觉得人们仍然会对这些事情充满热情。平均水平的大学教育可能要面临困境：你也许不必再上大学，可以自己学习，然后找到工作。但一直以来，真正推动行业进步的都是最顶尖的那群人。他们总会找到方式满足自己的好奇心，去探索什么做法可能更好。就像有人会休假一年去 Recurse Center，专门研究有趣的编程问题，哪怕他们在业界本可以赚很多钱。
对，确实如此（笑）。你们两个人之间有什么分歧？很少能在播客里同时请到你们两位，我想把这个问题问出来。
我觉得我们合作效率很高，一个原因是有时我们确实意见不同，但对方稍微坚持一下，另一个人就会说：“嗯，也许你是对的，我们试试看。”所以最后不会闹出严重冲突。很多分歧其实没那么重要；只要大方向正确，事情就会顺利。
你们也太想不出分歧了吧（笑）。
确实（笑）。我们没有为此争到翻脸，因为事情从没重要到值得我们为它激烈争论。而且我们都很忙，各自负责业务的不同部分。
也许是因为公司一直在成长，各自有自己的职责，所以必须合作。
是啊。
有意思。Laura、你们三个人都参加过新加坡的 Entrepreneur First。当时你们各自做不同的公司，结业后你们两个还继续住在一起。
对，我们七个人住在一栋房子里，各自做不同的初创公司。那时我们还没创办 Supabase。
不知怎么的，你们发现彼此很适合合作，于是一起做了这家公司。
对。通常在加速器里，技术人员会被安排和某个行业领域专家搭档。但我们住的房子里七个人都是建设者、技术人员。我们发现这样的组合效率高得多；尤其做开发者工具时，开发者自己就是领域专家，我们能完成更多事情。后来我们也把公寓里的很多人招进公司。
Rory 是……
他是第一个员工吗？
不算第一个，但他是最早负责 GTM 的人，现在负责整个 GTM。
做 Postgres 的那位是第一个？
不是，是 Angelico。
Angelico，对。我们还有一位实习生。
他是我上一家创业公司的实习生。
我们就把他一起带过来了（笑）。另外，最早的全职员工之一是 Steve Chavez，他是 Postgres……
开源软件的未来
……Postgres 的维护者。YC 给创业公司的建议通常是：“我们会给你一笔钱，但别急着招人。”大家很容易忍不住组建大团队。我们去问 YC 的合伙人：“我们认识 Steve，他是 Postgres 的首席维护者。”对方说：“马上把他招进来！”（笑）
是因为他的名气，还是因为他确实适合 Supabase？
两者都有。他擅长的技术是我们非常依赖的，所以我们决定大力投入。有趣的是，招到 Steve 后，我们告诉他：“别担心 Supabase 的事，继续把 Postgres 做好，让它变得更棒。”如果有支持请求，我们会去问他；后来 Steve 想扩大 Postgres 团队，我们就继续招聘专门做这个项目的人。这个模式效果很好。
你们为社区和开源做了很多。我一直在想大型商业开源项目的未来。一方面，AI 生成了很多低质内容，我想你们也在应对；另一方面，过去依赖的工具现在可能变得可有可无，因为人们可以随手用 vibe coding 重做任何东西。你们怎么看开源的未来？
用 Rust 重写软件是一种可行方式。我们团队有人曾说：“我要把我们做的所有东西都用 Rust 重写。”我就问：“你打算重写到哪一层？要重写数据库吗？要重写 Postgres 吗？Postgres 不是用 Rust 写的，但我怀疑你是否真在意到那一层。”
有些层值得重写，但不应该把真正用于创新的时间和资源全花在重写上。未来可能很多工具都会迁移到 Rust——如果最后证明它速度更快、更正确的话。很多开源工具大概都会经历这种变化。不过，当这一轮改造完成，系统已经运行在高效语言上后，人们不会每次都把所有东西再重写一遍。最后会有少数赢家。
一个经典例子是 Postgres。它是用 Haskell 写的，这是一种很不常见、维护起来很困难的语言。现在能用 Rust 重写吗？大概可以。它的功能仍然有价值；如果真的发生这种事，可能会有一个 Rust 版 Postgres 分支，成为这个类别的赢家。
但你们还没这么做，而且你们有不少东西是用 Elixir 写的。
对。这就要看基础设施。Elixir 是一门很有意思的语言，因为它运行在 BEAM 上。接下来你还得考虑运维时哪种机制才合适。
不过，现在只要测试都通过，就能比较轻松地切换范式。
对，这个观点不错。我还真没怎么想过要不要把 Elixir 换成 Rust。
现在这成了一个可以选的方案。Vercel 的 Malte 有条推文我一直记得：他预留了一笔钱，把所有依赖——包括 C 或 C++ 层——都重写成 Rust，因为 Rust 更安全、更正确，诸如此类。
这相当于给开源生态做一次性升级。
对，包括驱动程序，以及你们使用的各种东西。我觉得这是个挺有意思的想法。
我也挺喜欢这个想法，但我不认为它会发生，因为大家都喜欢自己动手做。
是啊。
不过作为一个想法，我觉得我们公司会百分之百支持。
太棒了。接下来是个本来应该早点问的收尾问题：Supabase 内部的 AI 编码……
社区与公司工作方式
Supabase 显然是编码智能体的受益者。你们内部的政策是什么？花了多少钱？会担心支出吗？Supabase 一直像是许多初创团队拼在一起的公司，所以我们坚持让各个团队自己决定用什么工具、怎么协作、怎么设置汇报关系。AI 政策也差不多：很多人问编码 AI 的政策是什么，我们就说由各团队自己决定。我觉得我们已经开始在少数方面统一管理，尤其是成本；但只要可能，我们还是想让团队自主决定如何运作。整体上非常去中心化（笑）。
我一直在想，能不能给公司负责人一个参考数字，说明市场上的支出水平。有些人说，个人平均每月花 20 美元，员工平均每月 200 美元。OpenAI 的中位员工可能每月花 3,000 到 5,000 美元；最高的那一档可能是几十万美元。大致如此。我觉得有个好指标是 Token 支出和人工成本的比例。很多人的比例可能是每 1 美元工资花 0.10 美元买 Token；到 1 比 1 也许还算安全，超过 1.5 可能就有问题。大概是这样。
我们是远程公司，幸运的是几乎所有发生过的事都有记录。
所以我可以问公司 AI 花了多少钱。目前每月大约花 30 万美元。
对，600 个人的话……
不是 600，是 450 个人。
450 人，明白了。这样大家有个概念。你说可以按员工人数来考虑成本，这对我们也有启发，因为我们正在快速招聘。只要额外投入能带来很多杠杆……
那应该是合理的。
没错。你们就需要一大批按需伸缩的“无服务器员工”。
对。另一家顶级初创公司的 CTO 曾担心公司的 AI 支出。我跟他说，这其实是对每个员工能力的投资，而且支出很不均衡：公司里可能有两三个人用得非常多，其他人可能根本没用。
是啊。
我们也看到同样情况。我们有个排行榜，把它贴出来后，大家通常会有点不好意思（笑）。
因为你们可能在浪费钱？其实重点也不该是花了多少，而是从系统角度看，你们到底解决了多少端到端流程，哪些流程已经不需要人参与，或能把原本很长的人工流程压缩成很短的流程。我们主要在这些方面投入，思考如何使用 AI。
幸好正如你看到的，Supabase 发生的每件事都记录下来了，因为我们是异步工作的公司。围绕 Supabase 建立一套公司级的 AI Harness，基本就是把现有流程正式化。你可以让 AI 读取这些资料，问“我们的原则是什么”，它就能根据公司历史记录总结决策原则。这正是我们投入很多时间的地方。
在说到员工之前，我想提一下我们现在大概有 50 个职位空缺，而且完全全球远程。我们不在乎你住在哪里，只要你足够优秀……
所以不管住在哪里，薪资都一样，对吧？
对，薪资不因居住地而异。如果你擅长自己的工作，欢迎看看我们的招聘页面。
能不能挑一个你现在最想招的职位，说说你们在找什么、为什么？
SRE。嗯……
远程招聘与站点可靠性
SRE。嗯。
为什么？
因为公司增长速度太快了，我们需要尽可能多的 SRE。
你们收到很多 SRE 申请。什么特质最突出、最能打动你们？
我们最看重的是，你确实想要远程工作。听起来有点奇怪，但确实如此。我们会收到很多优秀候选人，不过想在 Supabase 适应并表现出色，你必须能在远程优先、完全异步的环境里如鱼得水。这种工作方式并不适合所有人，我们很早就意识到了。有些人入职后会说：“我需要见到真人。”
我印象里的 SRE 就是那种留着灰胡子、坐在某个地下室里、不想和人说话的人。
那正是理想人选（笑）。这样的人都来申请吧。
希望他们会听这期节目。
我想我们确实有不少留着很棒胡子的 SRE（笑）。我以前公开说过，AI SRE 是智能体创业公司最难攻克的领域之一。我可能很快就要改口，但到目前为止我还是对的：AI 还没有攻克它，不知道为什么。
对，暂时还没有。我同意。
写软件这件事还有争议，但解决问题、维护系统、让它持续运行完全是另一回事。
对。
这确实是另一回事。
好，谢谢你们一直帮大家把系统运行下去。祝贺你们走过的这段路。我很自豪能做你们的朋友和投资人，也很高兴看到你们一路进步。我迫不及待想等你们 IPO——虽然看起来还要过些时候，但一定很有意思。我真的很想看到你们敲响上市钟声，打造下一家伟大的开源公司。太棒了。
当然，谢谢你邀请我们。