Supabase打造10亿个AI生成应用的计划

摘要

• Supabase要实现“10亿数据库”愿景，既需要更低成本的起步方案，也需要一条通往大型生产负载的可信路径。 创始人称，Supabase每月上线500万个数据库，预计未来需要数十亿个；收购Turso带来了面向小型、文件型数据库的技术。Supabase Spark旨在实现“任何想法都能配一个数据库”，用户可升级至完整Postgres，最终再迁移到适用于更大负载的Multigres。
• 模型能力提升，正同时改善获客、激活和付费转化。 创始人称，Agent驱动的用户激活率接近100%，这类用户转为付费账户的比例也高于传统开发者。Paul说，一位客户在上线头几天就赚到了他估计约1万美元，这改变了他们对vibe coding的判断：“人们正在做出真正的东西，并靠它赚到真金白银。”
• Supabase按销售介入后带来的增量增长给销售人员发放报酬。 在Paul举的例子中，没有回应的账户月环比增长25%，得到协助的账户增长125%。Paul将两者差距称为“100%的增量提升”；销售人员的任务是找出问题、帮助用户，产品遥测数据和AI生成的脚本则为他们提供支持。
• 企业扩张仍以开拓新业务为主，因为生产数据库极难替换。 Paul预计，未来5年企业业务几乎所有精力都会投向新工作负载。代码Agent或许能简化旧应用的重写，但可能威胁营收的停机，以及双主状态下的数据对账，仍是迁移障碍：“我敢保证，他们几乎永远不会迁移。”
• 在Supabase的优先级中，AI实验室和产品驱动增长都排在企业销售之前。 Swyx回忆，Supabase曾认为产品驱动增长可能会在1亿至2亿美元的规模触顶；如今他们问的是：“能做到10亿美元吗？20亿美元呢？”CPU短缺也让基础设施获取成为战略问题；随着新投资方CapitalG加入，Supabase正在考虑GCP以及与Alphabet建立更深层的关系，CapitalG可为其对接Alphabet生态。
• Supabase既把社区参与视为分发渠道，也认为社区成员应当获得股权回报。 在发现传统众筹限制太多后，公司划出100万美元股票，准备分给社区成员。首位将被重点介绍的成员Gary Abbott，6年来回答了2万个社区问题，其中1.3万个在1小时内得到解答。
• Supabase内部AI投入不小，但运营目标是让AI完成整个流程。 Ant称，公司450名员工每月的AI支出约为30万美元，各团队大多自行选择工具。异步文档为公司级AI系统提供了基础；创始人也认同，让AI维持生产基础设施稳定运行仍未解决：“还没有。”

精读

1. Postgres扩展从兼容性与故障测试开始

• Paul宣布，性能项目OrioleDB取代了Postgres的Heap存储引擎，号称速度快1.5至2倍：“其他地方什么都不用改。”它还免去了vacuum和膨胀清理等部分后台任务。Supabase收购了这项技术，持续推进开发，并为其专利支付费用；如今将以Apache 2.0协议发布完整Beta版，该协议涵盖这项专利。

• 这套引擎通过了pg_regress兼容性测试、Antithesis、每晚运行的TPC-C基准测试和Jepsen测试。Multigres针对的是另一类可靠性问题：Paul称，他们检查过的每一种Postgres运维工具，都可能在某些条件下丢失数据。Supabase重写了运维工具架构，并报告称已连续完成1,000次故障切换且没有丢失数据；平台初期将通过邀请方式向有严肃生产需求的用户开放。

• 分片工作尚未完成。Paul回忆Sugu从Vitess项目中学到的一条经验：“我想先只专注于兼容性”，也就是说，应用迁移到分片版Postgres后，查询最终应保持不变。部分分片功能预计明年初前后落地，具体取决于平台进展。设计合作伙伴包括Booz Allen、Postman和Perplexity；该项目也将面向Supabase自有服务以外的用户开源。

2. Turso为数十亿个小型数据库提供架构

• Supabase目前每月上线约500万个数据库；创始人认为，未来公司需要支持数十亿个数据库。如果每个原型项目都配一套独立的Postgres集群，现有计算资源将不堪重负。收购Turso解决的是另一种扩展问题：小型数据库需要经济实惠的文件格式；高要求的事务型应用则仍可通过Postgres和Multigres获得独立的升级路径。

• Paul介绍，Turso的架构是在SQLite周边加入MVCC能力，包括支持多个写入者。Turso的重写为兼容Postgres铺出了路径，这促使Paul主动联系Glauber。Paul认为，对象存储有“11个9”的持久性，能替代数据库集群所需能力的一部分。Swyx特别指出，持久性和可靠性不是一回事。

• Turso将保留自己的品牌，并继续专注SQLite。Supabase Spark会推出一种更小的实例类型，并兼容Supabase的各类库：“任何想法、任何原型，都能配一个数据库。”预期的升级路径是从Spark到完整Postgres，再到Multigres。创始人认为，无停机迁移是硬性要求：一个实验项目如果登上Hacker News首页，也必须有地方继续扩张。

3. 算力解除执行限制，CPU短缺左右战略

• Supabase Compute针对的是Edge Functions所设定的2秒执行时限。它支持长时间运行的无服务器容器负载，包括Rust、Python、Agent、分块处理和嵌入任务；这些负载可在数据库的私有网络内运行，并直接连接Postgres。此前缺少的基础能力是算力，如今持久化工作流终于可以搭建；社区过去曾尝试在Edge Functions上实现这类工作流，但都遇到了超时问题。

• Supabase已经需要与AWS密切规划容量，并支付更高费用。Paul将新投资方CapitalG与Alphabet的AI产品及多云战略联系起来：“我们需要更多算力。”GCP显然是下一个候选平台，不过Paul明确表示，他不知道GCP的对象存储是否具备S3所有相关功能。

• Swyx提到，S3 Express的写入时间为1至2毫秒：应用把数据放到足够持久的存储位置后，就可以先确认写入，再在后台将数据迁至更便宜的S3，正如Ant所解释的那样。Swyx问Redis是否仍有必要；Ant给出肯定回答。Ant描述的存储层级依次是内存、NVMe硬盘、本地直连存储、相当于S3的存储，以及常规S3。

4. 更强模型让尝鲜者变成付费客户

• Paul将Supabase的AI增长分为3个阶段。第一阶段从嵌入开始：Andrew Kane的扩展帮助证明，Postgres也能承载向量负载。主打卖点是整合：“如果要存自己的嵌入数据，就没必要再用另一种数据库。”Paul还特别称赞了Turbopuffer采用了与Turso相似的存储创新。

• 第二阶段在2024年底随着Lovable和Bolt兴起。Supabase讨论过是否服务这些开发者，甚至考虑打造自己的竞品界面。公司的使命给出了答案：“存储世界的数据”意味着要在项目刚启动时就参与其中，包括玩具项目，同时相信工具会不断进步。与此同时，现有客户也需要能够承载更大规模业务的基础设施。

• 变现让这次转变变得具体。Paul说，他估计有位客户在上线头几天就赚到了1万美元。Agent辅助接入Stripe后，项目第一周内就能开始收款。MagicSchool则是另一个例子：其创始人原本是一名教师，发现教学中有重复性任务后，便在没有传统技术联合创始人的情况下创业。

• 第三阶段始于今年年初模型能力提升之后。营销支出不多，注册量却加速增长，激活和付费转化也同步上升。Agent会自行完成设置，激活率因此接近100%；创始人称，这类用户比传统开发者更容易转为付费账户。Swyx用一句话概括：“摩擦消失了。”（“Friction’s gone.”）

5. 社区分发，正在成为模型分发

• Supabase最初以“Realtime Postgres”为定位，几乎无人关注。改称“开源Firebase替代品”后，大约12小时后便有人主动在Hacker News发帖。用户数从8个跃升至800个，基础设施压力随即显现：48小时内，DigitalOcean约1万美元的额度就用完了；在YC第一周，团队又把800个数据库迁到了AWS。

• Swyx认为，Supabase受益于它比LLM爆发早成立了3至4年，并且挑战的是一个已有品类领导者。创始人承认时机有运气成分，但如今正在大力投入AEO。社区教程、视频和帖子为模型提供了可学习的材料；支持答复也被收集在GitHub Discussions，并同步到Supabase网站。

• 在律师反对没有合格投资者参与的大规模众筹后，创始人提出：“不如直接把股票给他们？”公司已划出100万美元，准备分给社区成员。Gary Abbott在Discord上以Gary Austin之名为人熟知，6年来回答了2万个问题，其中1.3万个在1小时内得到解答。这位退休后仍热衷折腾、还开发过一款葡萄酒应用的用户，将成为首位重点介绍的受赠者。

6. 产品驱动销售奖励带来增量增长的帮助

• Paul将Supabase称为一家“指数型公司”，称每届YC创业营中有60%的团队使用Supabase。Stripe是其标杆：这是一家开发者公司，花了十多年逐步向大客户市场扩张，同时始终受到开发者青睐。销售团队通过产品信号叠加在这种采用趋势之上，而不是取代开发者驱动的增长模式。

• 触发信号包括知名客户、规模扩张、错误、额度限制和支出。Paul举例说，每周会有1,000个触发信号和外联邮件，带来500条回复。使用模式能够揭示账户的问题，AI则可以协助准备沟通脚本。公司给销售人员的指示是：“跟这些人约个电话，帮他们解决问题。”

• 在这个例子中，没有回应的账户作为对照组，月环比增长25%；回应并获得协助的账户增长125%。Paul称两者差距是“100%的增量提升”，销售人员的薪酬也与这一增量挂钩。他反对传统配额制的理由是，销售人员可能因此获得本就会由产品带来的增长奖励。

• 企业需求也来自Supabase有意不追踪的自托管客户。Paul举例称，制药公司会运行100个实例。Control Tower把Supabase为Platforms开发的机群管理能力重新打包，为企业提供一个管理界面，用于启动、监控和管理内部数据库。Paul说产品明天就会发布，但不知道届时是否会正式宣布。

7. 代码生成更容易，数据库粘性依旧

• Paul对企业客户的判断异常坚定：“我敢保证，他们几乎永远不会迁移。”未来约5年，Supabase企业业务的重心几乎全部放在新工作负载上。企业希望让更多员工参与产品开发；借助Lovable和Supabase重新投入开发的CPO，也会自然而然成为高管层的支持者，无需公司额外培养。

• Swyx追问更大的机会：代码Agent是否终于能让企业从Oracle等遗留系统迁出？Paul承认，如今重写百万行存储过程可能容易多了。但他仍认为，优先事项是先进入企业内部；全面替换听起来很诱人，却一再被证明是数据库供应商难以攻克的难题。

• Paul的解释聚焦于OLTP的经济账。生产数据库支撑着产生营收的应用，停机1分钟就会带来收入损失。新旧系统并行运行则会造成双主风险，两边数据可能逐渐分叉；要把数据重新对齐并不容易。先把新工作负载放到别处，是一种可行路径。Swyx指出，这样做可能让客户背上两套系统的问题。

• Swyx还问，随着Lovable和Supabase的产品日益重叠，客户会更依赖哪一方。创始人强调数据库迁移难度很高。他们也肯定Lovable最早做到了防止Agent把图片塞进Postgres，或为了让应用正常运行而关闭RLS；更好的技能设计带来了改善，而新模型如今也更少犯这类错误。

8. 分析型工作负载需要独立架构

• 被问及Databricks的HTAP主张时，Paul表示Supabase尤其关注DuckLake和DuckDB。Swyx把DuckDB形容为“分析领域的SQLite”，它可以读取对象存储和Postgres。Paul说，Supabase倾向于让不同任务使用各自合适的技术。Swyx补充说，他没有仔细研究Databricks的实现，自己也可能记错了。

• 架构上的限制是物理层面的：本地NVMe容量有限；如果一个事务必须拆分到多台服务器，最终从对象存储取数据会拖慢数据库。Paul认为，分片是迈向PB级OLTP的最佳路径，分析工作负载则应单独处理。通过另一条路径读取共享的对象存储数据仍然可行；在他看来，“试图把这两者硬拼在一起”未必合理。

9. 实验室默认选型有望抬高产品驱动增长天花板

• Paul给出的优先级依次是赢得战略性实验室、赢得模型开发商、继续推进产品驱动增长；“企业业务排第4。”美国实验室获得最多关注，因为目前它们带来的流量最高；创始人也承认这一点将来可能改变。当AI产品创建应用时，Supabase能成为默认后端，是尤其理想的结果。

• 过去规模一直是实现这一角色的障碍。Paul假设ChatGPT拥有12亿月活用户；如果每个用户每月都对应一个数据库，就需要12亿个数据库。他将Turso技术视为实现这一规模的路径。这个例子说明的是潜在分发合作所需的容量，并非已经宣布的部署计划。

• Swyx回忆，Supabase曾认为产品驱动增长的规模上限可能是1亿美元，或许能到2亿美元，之后就需要采用其他销售模式。AI抬高了这一上限，但创始人不知道现在的天花板在哪里：“能做到10亿美元吗？20亿美元呢？”同事担心会让团队失望的一项营收目标，最终约4个月就达成了。

10. 声明式文件让Agent更容易理解后端

• Paul描述了开发方式的演进：从依赖控制台，到使用API，再到代码优先、Git原生的工作流。本地Supabase文件夹代表整个后端，包括函数和数据库结构。新的pg-delta库支持Postgres声明式Schema，可描述表、策略和注释，也能用于Supabase以外的Postgres数据库。

• 对Agent来说，迁移历史不是理想的读取界面：要判断一张表目前是什么结构，可能得重建1,000个文件的变更过程。启动本地数据库、重放迁移并检查结构也需要时间。声明式Schema可以直接提供当前状态，让Agent在文件系统上快速迭代。

• Ant进一步追问：如果个人Agent几乎能瞬间生成应用，人们最终会创造什么？Ant已经在尝试用手机开发，也承认基础设施知识有助于指导Agent。“我想做X”之后一秒就出现一个可运行的应用——这个想象中的终点，正在指引今天的工具选择。

• Swyx提出，Agent可能都收敛到同一种做法，让开发停留在局部最优。Ant认为，品味不足、随手尝试的开发者可能会采用模型的常规做法；有鉴别力、技术水平高的人仍会在意细节。Paul追问这些高水平开发者今后如何培养；Ant认为，顶尖开发者仍会保持自学和好奇心。

11. AI辅助重写周期后，开源项目或将整合

• 早期一次招聘经历体现了Supabase对依赖项目的态度。尽管YC通常建议不要过早扩张团队，YC的一位合伙人仍鼓励他们聘请Postgres维护者Steve Chavez。给他的任务基本就是：“不用操心Supabase。”继续改进Postgres；随着团队发展，Supabase会为这个项目聘请更多专职人员。

• Ant认为，如果Rust确实能让实现更快、更正确，许多工具可能会转向Rust。这或许会催生少数胜出的项目，而不是无休止地各自重写；开发者应该留好自己的“创新额度”。Ant也提到Elixir和BEAM在运维层面的取舍。创始人认可设立一个协同资助依赖项目重写的基金，但Ant怀疑开发者会因此放弃自己做一套。

12. 内部AI投入瞄准完整流程

• Ant形容Supabase像是“几家初创公司粘在一起”，各产品团队自行选择工具和工作方式。AI政策大体延续了这种自主权，不过公司开始集中管理成本。Ant查阅内部记录后称，公司450名员工目前每月的AI支出约为30万美元。使用量似乎集中在少数员工身上。

• Swyx和Ant认为，AI支出排行榜可能会让人盯错指标。真正该问的是，AI能在无人干预的情况下完成多少完整流程，或者能把长期工作压缩多少。Supabase的异步文档让搭建公司级AI系统成为可能：积累下来的记录能够提供决策、背景信息和运营原则。

• 可靠性仍然需要靠招聘补足。Supabase目前约有50个职位空缺，尤其需要SRE；公司支持全球远程办公，薪酬不受所在地影响。能适应完全异步的工作环境是实质性要求。Swyx称AI SRE仍是最难攻克的创业方向之一；Ant认同，让AI维持系统稳定运行的问题至今还没有解决。