编程智能体为何选择 Supabase：架构、社区分发与持续运维

一、嘉宾背景

Paul Copplestone 与 Ant Wilson 是 Supabase 的两位创始人。嘉宾介绍将 Supabase 描述为一家完全远程办公的开源公司，提供 Postgres 数据库托管及相关开发服务。建设数据库平台、回应开发者需求，以及支持客户将应用从原型扩展到更大规模，构成了两人讨论智能体基础设施的经验背景。

这期 Latent Space 由 Alessio Fanelli 和 Shawn swyx Wang 主持，时长约77分钟。访谈围绕 Supabase 对编程智能体的吸引力展开，涉及计算产品、数据库架构扩展、社区与增长、企业采用，以及公司内部的 AI 使用。

两位创始人回忆，他们相识于新加坡的创业环境，曾与其他技术开发者合住，后来还招聘了多位室友。谈到合作中的分歧时，他们强调通过试验检验建议，并划分职责、分别处理不同业务。这种合作方式也为理解节目中的工程取舍提供了背景。

节目开场披露了主持人对 Supabase 的种子轮投资，以及涉及 AI Engineer 和 Latent Space 的赞助关系。阅读访谈中的产品评价、性能数字和增长叙述，需要同时保留这一利益关系背景，并区分主持人的判断、创始人的主张与已经报告的测试结果。

二、本期主要内容

产品讨论从长时间计算的需求展开。应用连接数据库之后，数据分块、生成 embedding 和运行智能体仍可能需要持续执行。创始人将原有函数的限制描述为约两秒，并介绍 Supabase Compute：它支持长时间运行的容器，可使用 Rust 或 Python，与数据库处于同一私有网络，直接连接 Postgres。这项产品试图减少运行环境的限制，以及计算与数据库之间的距离。

主持人进一步谈到轻量启动、声明式 schema 和运维信息。日志、检查、连接资料、SQL 文档与 skills，都会影响智能体能否理解问题并继续操作。创始人介绍的 code-first、Git-native 方向，则要求文件直接表达数据库的当前结构，使智能体无须从约一千份迁移文件中重建状态，也无须先启动本地数据库再检查其结构。面向 Postgres 的 pgdelt 是其中一项具体工作，扩展后的 schema 支持则作为会议发布内容讨论。

数据库层面的发布回应了三类规模需求。OrioleDB 面向单库性能：创始人称，它可以兼容替换 Postgres Heap，带来约1.5至2倍性能，并消除 vacuum 和 bloat 相关工作。他们介绍了兼容性与故障测试工具，宣布完整 beta，并说明 Apache 2 许可覆盖相关专利。Multigres 则面向集群管理。创始人称，团队评估过的 operator 在某些条件下可能丢失数据，因此决定重写管理层；重写后完成了一千次连续故障切换，未发生数据丢失。项目开放源码，托管服务初期通过邀请提供。访谈时，分片尚未发布，无须修改查询和应用代码仍是兼容性目标；部分能力暂预计于次年初交付，进度取决于平台依赖。

第三类需求来自实例数量。创始人报告，平台每月启动约五百万个数据库，并预计未来需要支持数十亿个。他们宣布收购 Turso，计划保留其 SQLite 方向，同时推出兼容 Supabase 客户端库的 Spark 实例，并提供向 Postgres 和 Multigres 升级的路径。他们以教师创办的 Magic School 说明，使用者也可能是非技术背景的构建者。要让这些用户的应用继续扩张，升级过程就需要足够平滑；跨后端零停机迁移因此被提出为必要条件，访谈并未展示这项能力已经完成。团队同时报告了计算容量压力。

对象存储是支撑小实例架构的一项基础。节目引用 S3 Express 约一至两毫秒的写入时间，讨论先完成持久化、再由后台转入较便宜存储的安排。发言者同时区分持久性与可用性、可靠性，并明确指出，S3 Express 不能因此被视为 Redis 的替代品。创始人倾向于为大量小数据库和重型事务负载采用不同架构。

容量压力也贯穿了公司的增长经历。据创始人回忆，早期将产品定位为“开源 Firebase 替代品”，并获得外部 Hacker News 曝光后，用户从约八人增至八百人，约一万美元的云额度随之耗尽。进入 YC 的第一周，团队就将约八百个数据库迁移到了 AWS。他们把后来的 AI 增长分为 embedding、2024年末的 vibe coding，以及随后模型能力提升三个阶段，并以早期客户的营收经历说明变化，声称激活率和付费转化有所提高。这些增长使平台需要同时承接小型原型和大型负载；相关效果数字仍缺少完整统计口径与样本。

三、核心观点：推理、例子与边界

让智能体可靠地操作数据库，需要同时提供当前状态、执行环境和故障信息。声明式文件帮助它理解数据库结构，Compute 为长任务提供运行环境，日志和连接信息则帮助它判断操作结果。这些能力各有作用：理解表结构之后，任务仍需要合适的运行环境；任务运行之后，还需要足够的信息定位故障。主持人认为，这些改进也让人类开发者受益，其价值因此不依赖某一种智能体界面能否长期流行。扩展后的声明式支持仍有发布安排，具体环境具备哪些能力，还要以实际交付为准。

Supabase 面对的规模问题也有不同层次。OrioleDB 的性能主张针对单库效率，Multigres 的管理和分片针对集群，Turso 与 Spark 则回应大量独立小数据库的资源需求。提升单库吞吐量，并不能自动降低创建数十亿个实例的成本；适合小数据库的文件与对象存储架构，也未必适合大型事务负载。创始人明确区分持久性与可用性、可靠性，并反对把 S3 Express 当作 Redis 的替代品。判断架构收益，需要回到具体延迟要求和负载条件。

技术发布中的测试结果、现有能力和未来目标，也需要分别看待。团队报告的一千次连续故障切换未丢失数据，只能说明这组测试的结果，不能覆盖所有故障组合。OrioleDB 的兼容性和故障测试是评估依据，但访谈没有提供对其约1.5至2倍性能主张的独立负载比较。Multigres 无须修改查询和应用代码的透明分片仍是目标；Spark 的升级路径也不能因收购已经宣布，就被视为已经完成。这些条件限定了读者能够据此作出的判断。

社区长期积累的知识，可能正在通过模型推荐获得新的传播渠道。主持人说，他的 AEO 跟踪显示，前沿模型会将 Supabase 推荐为一体化后端。创始人推测，早期教程、视频、播客和开源材料进入了模型训练，使公司获得时机上的优势。访谈没有确认具体训练材料，也没有区分品牌、产品能力与内容积累各自的影响。更明确的实践，是把有用的问答整理进 GitHub Discussions，再镜像到官网，让反复出现的问题能够复用已有答案。创始人称，Gary Abbott 六年间回答了约两万个问题，并介绍了约一百万美元的社区赠股安排。在他们的叙述中，社区贡献有明确的组织价值；相关规模数字仍来自公司口述。

企业采用则显示，获得推荐与替换现有数据库之间，还有很长的距离。创始人优先争取企业新项目，再随客户扩张；Control Tower 则将已有的平台数据库管理能力用于企业内部实例管理。公司刻意不追踪开源部署，因此无法从这些信息推导完整安装规模。CPO 借助 Lovable 和 Supabase 开发内部工具，为新项目带来了使用者和支持者，但核心生产数据库的切换还受到业务连续性的约束。

创始人指出，OLTP 数据库承载着直接关联营收的应用，停机可能造成损失；新旧系统并行又可能出现脑裂，留下难以对账的数据。代码生成降低了应用重写成本，却只解决了迁移的一部分问题。早期智能体的行为也暴露了另一类约束：为了让应用运行，它们曾关闭 RLS，或把图片数据写入 Postgres。嘉宾认为，Lovable 的 skills 改善了这些行为。评估智能体是否完成任务，因而既要看功能是否可用，也要看权限和数据约束是否得到保留。

增长数字同样需要结合口径理解。创始人将接近百分之百的注册到激活率归因于智能体自动配置，并报告付费转化有所改善，但没有给出完整定义、样本和观察窗口。产品驱动销售的比较更具体：未回复者的账户月增长约25%，接受帮助者约125%，销售激励依据团队认定的增量计算。然而，两组按是否回复、是否接受帮助划分，回复者可能原本就更积极、需求更强，增长差不能全部归因于销售介入。可供借鉴的是围绕实际产品问题提供帮助的方式；这些口述比例还不足以直接用于增长预测。

四、学习与应用

构建智能体开发环境，可以从实际任务所需的信息入手。数据库策略修改、embedding 计算等操作，需要当前 schema、相关策略、执行入口和失败日志。评估时应检查，智能体是否仍要遍历大量历史文件、猜测连接方式，或通过关闭权限约束绕过错误。验收应覆盖任务结果与约束是否同时成立。声明式文件也需要与实际数据库状态核对，否则清晰的文件表示仍可能与运行环境脱节。

基础设施选型首先要明确，当前问题是单库效率、集群管理，还是小实例数量。性能主张需要用自身负载验证，故障切换结果需要结合测试覆盖的条件理解。Spark 升级路径与透明分片能否成为当前交付的依赖，则取决于实际可用阶段。分析需求也应按负载选择技术。嘉宾提到 DuckDB、DuckLake，并倾向于用分片承接超大型 OLTP；这体现了按用途选择架构的立场。主持人明确保留了对 Databricks HTAP 的理解可能不准确这一点，因此不能将这段讨论扩展为对所有 HTAP 实现的判断。长时间计算为工作流提供了更多可能，访谈并未据此确立一个已经完成的持久工作流产品。

企业采用新应用与迁移核心数据库，需要不同的评估重点。内部新工具可以先验证开发速度和管理方式；存量营收系统则需要明确停机窗口、并行期间的数据归属、切换步骤和对账安排。拆出新负载时，也要计算长期维护两套系统的成本。销售团队可以通过产品信号识别客户遇到的问题，但衡量帮助效果时，需要考虑客户原有的增长趋势、回复意愿和需求强度，避免将观察到的增长差额直接计为销售带来的因果增量。

社区知识的复用，可以从反复出现、适合公开的问题开始：整理答案，并维护可检索的公开入口。Supabase 将有用问答迁入 GitHub Discussions、再镜像到官网的做法，提供了具体参考。知识复用的效果与其是否影响模型推荐，需要分别观察。

上游维护则需要持续投入。创始人介绍，他们招聘 Steve Chaves 后，让他继续维护关键上游项目，并出资支持更多贡献者。转录对该项目名称的表述不一致，其确切身份仍有歧义。这段经历能够支持的做法，是为关键依赖的维护能力投入资源；判断替换成本时，也需要把维护者和运行机制考虑在内。

评估 AI 辅助重写，应先明确组件边界、测试覆盖和依赖层次。嘉宾以 Elixir 的 BEAM 说明，语言替换可能牵涉整个运行基础设施。代码最终向 Rust 收敛仍是预测，能够生成替代实现，并不足以证明迁移值得进行。内部 AI 预算也需要结合实际结果理解。创始人报告，公司当时约有450人，每月 AI 支出约三十万美元；团队可以自主选择工具，公司则进行一定程度的成本整合。这些数字描述的是 Supabase 当时的使用状态，不能直接作为通用预算标准。

衡量内部 AI 使用，可以从有记录的重复流程开始，比较端到端完成情况、人工接管次数和耗时，再结合费用判断效果。节目承认使用量集中于部分员工，也提到内部排行榜，但讨论更重视完整流程能否完成、任务耗时能否缩短。Supabase 正尝试利用长期异步工作积累的历史文档，搭建公司级 agentic harness，访谈没有报告已测得的生产率收益。历史决策的适用条件也需要一并保留，避免旧原则脱离背景后被反复套用。

持续运维仍需要明确的责任安排。创始人介绍，公司在全球招聘，薪酬不因所在地而变化，并强调员工能否适应完全异步的工作方式，尤其是在 SRE 招聘中。主持人与创始人都认为，当时 AI 尚未解决让系统持续运行的问题。软件创建速度提高之后，运行责任、故障处理和长期可靠性仍需落实。

来源

• 原始节目：Why Agents Love Supabase — with Paul Copplestone and Ant Wilson