Why Agents Love Supabase｜深度中文详解
- 日期：2026-10-28
- 时长：4598 秒（1 小时 16 分 38 秒）
- 音频：收听 MP3
- YouTube：观看视频
- Episode：节目页面
- 英文转写来源：youtube-captions
主持人在开场说明，自己六年前参与了 Supabase 的种子轮天使投资，且 Supabase 曾赞助其相关活动、也将赞助 Latent Space。因此，这场访谈既有长期观察者才能提出的细节问题，也存在明确的利益关联；涉及估值、性能、增长和市场地位的说法，尤其应区分受访者陈述与独立验证的事实。
访谈围绕 Supabase Select 的产品发布展开。两位受访者是联合创始人 Paul Copplestone 与 Ant Wilson。理解本集需要先分清三种「规模」：单个数据库跑得更快、大型数据库或集群处理更重的负载，以及平台同时容纳海量小数据库。OrioleDB、Multigres 和收购 Turso 后规划的 Supabase Spark，分别主要回应这三类问题。
本集的主线不是给 PostgreSQL 加上一层「AI」标签，而是重新设计从创意到生产环境的后端路径。主持人看重两项基础变化：Supabase 希望降低本地启动的负担，并让数据库的目标结构以文件形式留在 Git 中；对编程智能体而言，这比翻阅漫长的迁移历史、反复启动数据库推断现状更直接。两位创始人则从平台两端补齐这条路径：新计算产品让长时间运行的任务靠近数据库；OrioleDB 改善存储性能，Multigres 面向更大、更可靠的部署；收购 Turso 则服务于大量轻量数据库的设想。
这套布局背后是需求形态的变化。受访者称，AI 建站工具与模型推荐同时推高了项目创建量和付费转化，使 Supabase 必须既接住随手创建的小应用，又不能让成功项目在增长后被迫换平台。但节目也清楚暴露了愿景与现状的距离：Multigres 的分片尚未发布，Spark 到完整 PostgreSQL 的平滑升级仍需实际检验，而「模型推荐带来增长」也难单独归因。更有价值的判断是：智能体友好的基础设施，最终仍要用人类开发者熟悉的标准衡量——可读的配置、可靠的数据、安全的权限，以及可控的迁移风险。
- 开场：为什么智能体偏爱 Supabase — 00:00 🎧 · ▶️
- 联合创始人与 Select 发布 — 05:23 🎧 · ▶️
- 把计算放到数据库旁边 — 06:39 🎧 · ▶️
- OrioleDB 与 Multigres — 08:05 🎧 · ▶️
- 纵向扩展、横向扩展与 Turso — 12:50 🎧 · ▶️
- 开发者营销与表情包 — 17:53 🎧 · ▶️
- 意外走红与早期云迁移 — 23:15 🎧 · ▶️
- 向量、增长与 AI 推荐 — 31:03 🎧 · ▶️
- 产品驱动销售与企业增长 — 41:43 🎧 · ▶️
- 在线迁移与分析架构 — 49:38 🎧 · ▶️
- 为智能体准备的本地开发 — 58:43 🎧 · ▶️
- 社区、开源与公司内部工作流 — 1:06:43 🎧 · ▶️
💬 他们说了什么：主持人先披露投资及赞助关系，再用「构建、运营、扩展」概括发布会。他特别注意到无需 Docker 即可开始本地开发的方向、靠近数据库的计算，以及声明式 schema：与其让编程智能体翻阅一连串 SQL 迁移文件，不如让它从 Git 中读取当前目标状态。他也提到日志、检查和连接等运营信息需要更容易被工具获取。
💡 为什么重要：这里的「智能体友好」主要是降低环境启动成本、缩短理解数据库现状的路径，并提供足够的操作上下文。这些改进也让人类开发者受益，并非只能服务于 AI。
⚡ 争议点：主持人称公司六年间估值从零增长至约 100 亿美元，但节目没有提供估值文件；其投资人与赞助关系也要求读者对赞许性判断保持距离。
💬 主持人回顾与 Paul Copplestone、Ant Wilson 相识以来的六年，随即请两人概括 Select 的重点。回答从计算产品开始，再转向数据库存储、集群管理与海量实例架构；这也奠定了整场访谈的顺序。
💡 Supabase 不再只讲「快速做出原型」，还要回答原型成功后的运营问题。后续各项发布应放在同一条产品生命周期中理解，而不是视作互不相关的功能清单。
⚡ 录制发生在发布会之前，受访者多次以「明天发布」描述产品。节目播出后仍应分别确认公告、开源代码与实际可用范围，不能将预告等同于普遍可用。
💬 Paul 表示，既有的 Deno Edge Functions 有「2C」限制，社区希望运行文本切块、生成嵌入等更长的任务。新 Supabase Compute 被描述为可运行容器、Python 或 Rust 等工作负载，支持长时间运行，并与数据库处于同一私有网络，可直接建立 PostgreSQL 连接。
💡 过去开发者可能需要在别处部署任务执行环境，再处理网络、凭证和延迟。计算与数据共址，能简化应用后端及长时间运行工作流的架构；主持人也据此追问未来的持久化工作流。
⚡ 访谈没有给出新产品的价格、资源配额、故障恢复或持久化保证。Edge Functions 的「2C」也只是转写中的原话，不能据此自行推断其精确定义。
💬 Paul 称 OrioleDB 是面向 PostgreSQL 的替代存储引擎，约有 1.5–2 倍的性能表现，并可减少某些后台维护需求；团队对其进行了兼容性和压力测试，宣布以 Apache 2.0 许可推出测试版。Multigres 则从集群 operator 入手：团队称在测试其他方案时发现特定条件下的数据丢失风险，重写后完成了 1000 次连续故障转移且未丢失数据。其平台部署面向客户采取邀请制。
💡 两者解决的问题不同：OrioleDB 侧重单个数据库的存储效率，Multigres 侧重多节点管理、故障转移及未来分片。把两者混称为「数据库提速」，会遗漏可靠性与运维这一半。
⚡ 性能倍数依赖基准与负载；「其他 operator 都可能丢数据」也缺少节目内公开的复现条件。尤其要注意，受访者明确说 Multigres 的分片当时尚未发布，不能把未来「无需改查询即可分片」当作已验证能力。
💬 Paul 称平台目前每月创建约 500 万个数据库，未来设想是每月数十亿个，因此宣布收购以 SQLite 技术闻名的 Turso。规划是保留 Turso 品牌，并推出轻量实例 Supabase Spark：先给每个点子一个小数据库，产品成长后再升级至完整 PostgreSQL，必要时继续走向 Multigres。他同时承认，基于对象存储的轻量架构不适合所有高强度事务场景。
💡 给数十亿个小项目各配一个完整 PostgreSQL 集群，资源成本可能难以承受。Spark 的战略价值在于降低「创建一个数据库」的单位成本，同时保留成功项目向上扩展的路径。
⚡ 每月数十亿是目标情景，不是当前吞吐量；从轻量实例到 PostgreSQL 的兼容性、迁移停机时间与成本，均需产品落地后验证。「零停机迁移」在这里是关键要求，而非访谈已经证明的结果。
💬 Ant 谈到团队仍会定期讨论表情包，但做好开发者营销需要同时懂技术和开发者的幽默。两人还回忆，有外部作者总结了他们尚未写成内部文件的社媒策略；早期多次登上 Hacker News，也引发站方对发布过密和潜在偏袒观感的提醒。
💡 Supabase 的传播并非只靠购买流量。能让开发者愿意转发、评论和制作教程的内容，会形成持续的社区解释层；它后来也可能成为模型学习产品用法时接触到的材料。
⚡ 表情包与增长之间不能直接画等号。Hacker News 的讨论同时提醒团队：社区曝光是信任的结果，不应把占据首页当成可反复索取的营销资源。
💬 创始人回忆，早期「实时 PostgreSQL」的表述反响有限，改为「开源 Firebase 替代品」后，第三方很快将产品发到 Hacker News。一次发布让用户数从约 8 人增至 800 人。当时每个数据库占用 DigitalOcean 的两台、各 5 美元/月的实例；约 1 万美元云额度很快耗尽，团队随后在 YC 初期迁移约 800 个数据库，转向提供更高额度的 AWS。
💡 定位改变了用户理解产品的速度，而突发增长立刻暴露基础设施成本。今天讨论「每月数百万个数据库」时，早期每个项目两台实例的故事解释了为什么轻量实例架构如此关键。
⚡ 这些数额与时间主要来自创始人的回忆。DigitalOcean 当年的额度政策和双方完整沟通过程未在节目中呈现，不宜将这一案例简化为单方面的商业失误。
💬 Paul 把 AI 影响分为三阶段：先是 PostgreSQL 向量扩展支持嵌入数据；然后是 Lovable、Bolt 等工具推动的应用生成；再到模型能力改善，带来更快的注册增长。他称激活率与付费转化率也上升，因为智能体替用户完成了初始设置。主持人提出，多个前沿模型会推荐 Supabase 作为集成后端；创始人将其部分归于长期积累的开源资料、教程和社区内容。本章还谈到拟向社区成员赠予总计约 100 万美元的公司股票：他们称 Gary Austin 六年回答了约 2 万个 Discord 问题，其中 1.3 万个在提问后一小时内回复。
💡 模型推荐与自动完成配置，可能同时改变获客和激活：用户不一定先研究各项后端选型，编程智能体就已为项目选好并接入工具。社区内容的价值也从「帮助人搜索」扩展为「帮助模型理解」。
⚡ 主持人的推荐排名方法、查询集合与时间窗口未在节目中完整披露；受访者没有公布可独立复核的激活率和付费转化率序列。股票赠予的执行范围与条件也应以正式文件为准。
💬 Paul 称 Supabase 以产品使用信号触发销售支持，例如增长、报错或触及限制。他举例：每周若有 1000 个触发信号、发出 1000 封邮件，约 500 人回复；未回复者构成参照组，账户月增长约 25%，获得帮助的回复者约增长 125%。团队据此强调销售人员应解决实际问题，并重点争取企业内部的新项目，而不是强推已有核心数据库迁移。他另称约 60% 的 YC 每期项目使用 Supabase，但未说明统计口径。
💡 企业增长在这里不是放弃自助使用模式，而是给已经出现需求的账户提供支持。面向企业的 Control Tower 则把管理大量数据库的能力，包装为内部项目可用的集中视图与控制手段。
⚡ 回复与未回复客户并非随机分组，本来就可能具有不同增长潜力；125% 减 25%不能直接证明销售带来 100 个百分点的因果增量。企业采用率也需要明确「使用」的定义。
💬 两位创始人认为，迁移核心 OLTP 数据库的难处不只是改写存储过程，更在于业务不能停机；新旧系统并行时，又可能产生难以协调的「双主」数据状态。因此，Supabase 优先争取企业的新工作负载。谈到把事务处理和分析合为一体的 HTAP，Paul 表示关注 DuckDB、DuckLake 一类技术，但更倾向于为不同工作选择合适的工具：大型事务负载考虑分片，分析则另行处理。他也指出，新计算原语可能为未来持久化工作流铺路。
💡 这段为「从原型扩展至更大规模」划清边界。让新应用一路成长，与把现有关键系统无风险搬过来，是两项不同的工程承诺；分析查询与交易写入也未必需要由同一套执行架构承担。
⚡ 对其他厂商 HTAP 方案，受访者承认自己并未深入研究其具体实现。关于「分片最好」和迁移通常难以促成的判断，应视为其架构取舍与市场经验，而非适用于全部负载的定论。
💬 Paul 描述了从仪表盘优先，转向代码优先、Git 原生的开发体验。Supabase CLI 已能在项目中建立代表数据库和函数的目录；新宣布的声明式 schema 能把表、权限策略、注释等当前结构写成文件，并配套适用于 PostgreSQL 的 PG Delta。他的例子是：如果结构散落在 1000 个历史迁移文件中，智能体要回答「这张表现在长什么样」就得重放或推断整段历史。
💡 声明式文件让当前状态可搜索、可审查、可纳入版本控制，减少智能体频繁连接远端数据库的需要。迁移历史仍有审计价值，但不应是理解现状的唯一入口。
⚡ 文件中的目标状态如何与真实数据库持续对齐，尤其如何安全处理删除、重命名、数据回填和权限变更，访谈没有展开。Paul 对「对手机说出想法，一秒后应用上线」的描述也是未来设想，不是现有交付承诺。
💬 两位创始人回忆技术背景相近的成员如何一起创业，并讨论 AI 是否会让开源依赖更容易被重写。谈到内部编程智能体，Ant 表示各团队原则上自行决定工具，成本管理则开始集中；他现场查询称，公司约 450 人，AI 工具支出约 每月 30 万美元。团队更关注能否缩短端到端流程，而不只是看消耗量。作为远程、异步公司，既有文档也为内部 AI 系统提供了材料。他们还提到约 50 个招聘空缺，并强调站点可靠性工程仍难以完全交给 AI。
💡 本集最后把「让产品供智能体使用」延伸到「公司如何使用智能体」。文档化决策、团队自主权、成本观测和可靠性人才，都是工具投入能否转化为组织效率的前提。
⚡ 每月支出只是某一时点的自报数字，不能直接换算人均生产率。节目关于用 Rust 重写开源依赖的讨论偏推演；转写中还出现对项目实现语言的明显混淆，不宜照录为技术事实。
- Paul Copplestone、Ant Wilson：Supabase 联合创始人，本集主要受访者。
- 节目主持人：Supabase 早期天使投资人；开场主动披露投资和赞助关系。
- Supabase：以 PostgreSQL 为核心提供数据库及集成后端服务；本集讨论其计算、存储、集群和本地开发布局。
- Turso：节目宣布将被 Supabase 收购；其轻量数据库技术与未来 Spark 产品路线相关。
- OrioleDB、Multigres：分别对应 PostgreSQL 存储引擎改进，以及集群管理与未来分片方向。
- Gary Austin：Supabase 社区成员；创始人以其长期回答 Discord 问题为例，说明社区贡献。
- Lovable、Bolt：访谈中提到的应用生成工具，也是 Supabase 需求变化的重要背景。
「落地时就与他们同行，然后确保他们到第 1000 天、第 10000 天都愿意留下。」——Paul 谈优先争取新项目，而非强推核心数据库迁移
「想象让智能体翻过一千个文件，再问它：这张表现在是什么结构？」——Paul 谈声明式 schema 的必要性
「重点不该是花了多少钱，而是有多少端到端流程真正被解决。」——Ant 谈内部 AI 工具投入
以上为依据英文转写整理的中文意译，非逐字引文。
「当前状态」与「变更历史」应分开看。 数据库迁移文件解释系统怎样走到今天；声明式 schema 解释系统今天应是什么样。对人和智能体而言，两者互补：前者便于审计，后者便于理解和修改。真正困难的是保证两者以及线上数据库一致。
海量应用生成改变数据库的经济模型。 如果创建应用变得极其便宜，后端平台面对的就不只是更大的流量，还会有更多长期处于小规模、甚至很快闲置的项目。轻量实例能否保持低成本，同时提供可信的升级通道，是 Spark 路线的核心问题。
「被模型选中」不等于可以忽略安全默认值。 节目提到早期编程智能体会把图片数据塞进 PostgreSQL，或为让程序运行而关闭行级安全策略（RLS）。优质工具说明、技能文件和安全护栏，应帮助智能体避免这类看似快捷的错误，而不是只提高接入速度。
- 产品状态：分别核对 Supabase Compute、OrioleDB、Multigres、Turso 收购、Spark 与 PG Delta 的正式公告、许可证、访问条件及发布日期；尤其不要把尚未发布的分片能力写成现有功能。
- 性能与可靠性：OrioleDB 的 1.5–2 倍性能、Multigres 的 1000 次故障转移测试，以及对其他 operator 的比较，都需要测试方法、负载和复现条件。
- 增长与销售归因：每月数据库创建数、YC 项目使用比例、付费转化变化及销售支持后的增长差异，均为节目中的自报或举例；对照组并非随机实验。
- 转写准确性：英文字幕存在产品名、技术词与人名识别错误；其中对某 PostgreSQL 相关项目实现语言的说法明显可疑。技术选型不应仅依据这份字幕。
- 未来迁移承诺：Spark 与完整 PostgreSQL 的兼容边界、升级时的数据一致性和停机时间，须待实现细节和用户案例验证。
- 开发者：让编程智能体操作数据库前，把 schema、RLS 策略和必要的项目约束纳入代码审查；不要为「先跑通」接受关闭权限保护。
- 平台团队：评估新数据库产品时，分别测试创建成本、单实例性能、故障恢复及从轻量实例升级的路径，不要用一个吞吐量指标概括全部需求。
- 企业采购与架构团队：先选择低风险的新工作负载验证平台；若计划迁移核心 OLTP 系统，单独设计数据同步、切换、回滚与双主冲突预案。
- 使用 AI 工具的管理者：同时记录工具成本和流程结果，例如交付时间、人工介入次数、故障与返工；避免把 token 消耗量当作生产力本身。
