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