跳到正文
Founder Park · 微信公众号·· 3 小时前AI 评分63

Supabase CEO Paul Copplestone 谈 Personal Agent 的下一步是给每个人一个 Personal Database

Supabase 创始人:Personal Agent 的下一步,是给每个人一个 Personal Database

AI 导读

Supabase 联合创始人兼 CEO Paul Copplestone 在 YC 播客 The Lightcone 中表示,Personal Database 可能成为 Personal Agent 的重要一环。

正文

原创 Founder Park 2026-11-03 18:50 北京

Make something agents want

Personal Database 可能会成为 Personal Agent 的重要一环,而 Supabase 正好站在这个位置上。这家做开源 Postgres 后端的公司,已经是 Claude Code、Codex 等工具里默认使用的数据库。

它的使用者也在变。除了开发者和创业公司,越来越多的使用者是没有工程背景、靠 AI 给自己做软件的普通人,和直接替人操作数据库的 Agent。过去一年,Supabase 的注册用户从约 300 万涨到 1300 万,托管的数据库从 800 万个涨到近 5000 万个,现在每周新建超过 100 万个,今年收入预计涨 4 倍。新增使用里,大约 70% 来自 Agent。

这批新用户带来的是另一种负载:数据库数量极大,单个规模却很小。Supabase 联合创始人兼 CEO Paul Copplestone 算过一笔账,如果 ChatGPT 的 12 亿周活用户每月都做一个东西,就是每月 12 亿个数据库。今年 10 月,Supabase 宣布收购 Turso,这家公司基于 SQLite,一台服务器就能管理数百万个按需创建的数据库。接下来,Supabase 准备推出轻量的 Supabase Spark 承接刚起步的负载,同时继续把 Postgres 往 PB 级扩展。

既然用户以 Agent 为主,产品也要跟着改。Agent 不看 Dashboard,Supabase 就全面转向 Code-First。报错信息里,要明确告诉 Agent 该怎么修。

在最近一期 YC 播客 The Lightcone 中,Paul Copplestone 聊了这些变化,以及 Supabase 接下来要往哪里走。以下是对谈全文,经 Founder Park 编译整理。

⬆️关注 Founder Park,最及时最干货的创业分享


01

一年新增 1000 万数据库用户,

很多不是程序员

Garry Tan(YC):为了让大家感受一下 Supabase 涨得有多快,你们最看重哪些数字?去年这个时候和现在分别是多少?

Paul Copplestone:现在累计注册用户是 1300 万,一年前大概是 300 万。今年收入预计会涨 4 倍。目前每周会创建超过 100 万个数据库,我们管理的数据库接近 5000 万个,一年前只有 800 万个,这是一个非常大的拐点。

Garry Tan(YC):传统软件工程师还是你们最核心的用户吗?

Paul Copplestone:工程师依然占很大比例,而且他们现在用 AI 写起东西来几乎没有顾忌。但今年变化最大的,是一大批没有工程背景的 builder 开始进来。

有个数据挺反常。按以往的经验,注册量涨得快的时候,后面的激活率和转化率通常会往下掉。但今年这些指标全都在往上走,有点不可思议。

原因只有一个,现在的模型在构建应用这件事上已经超过了临界点。过去那些完全没有软件工程背景的人,打开 Claude Code 聊几句就能把前端跑起来,接着他们很快发现光靠本地文件走不远,于是顺理成章地带着 Agent 涌进了 Supabase。

早期投资人跟我说过,PLG(Product-Led Growth,产品驱动增长)做到某个收入规模就会到顶,到时候必须雇一堆销售去做传统企业市场。但因为「Builder」这个新物种的爆发,PLG 至今完全看不到任何天花板,我甚至不知道它的上限在哪里。

Harj Taggar(YC):上周末我正好聊到一个非常典型的「新 Builder」样本。他是一家估值超过 10 亿美元的 Fintech 独角兽创始人,本科学数学的,也会拼一些 Ruby 脚本,但以前真要把软件做出来,还是离不开工程师。

现在,他开始自己做副业项目。因为有多年 Fintech 经验,他可以为自己的个人财务搭建复杂的资产负债表、追踪工具和银行接口。这种高度专业、却只服务于极小众需求的软件,在两年前根本不可能被写出来。

Paul Copplestone:这类跨界领域专家恰恰是最理想的一类 builder。像我这样的程序员,脑子里能想到的创业点子永远局限在开发者工具里。但领域专家知道自己所在的细分领域还缺什么。现在他们不用先说服别人加入,就能自己钻进去做。

Garry Tan(YC):YC 招进来的创始人画像也在变。在 2022 到 2025 年间,我们很强调软件工程能力,觉得无论如何都要有技术联合创始人。但过去一年里,我们突然意识到,现在把东西造出来的能力已经变成了拧开水龙头就有的自来水,真正困难、稀缺的是「知道该造什么」。

在你们社区里,还有没有让你印象特别深刻的、由普通非程序员造出来的案例?

Paul Copplestone:前不久我们在旧金山办用户大会,散场后有一位来自巴西的大叔激动地跑过来找我。他是一名普通的出租车司机,大概 50 岁,只用手机就做出了一套完整的出租车应用,有点像服务当地市场的小型 Uber。

我其实不太清楚他为什么要做这个,但他能做出来、过来找我的时候特别感激。他 50 岁了,身上却有一股刚开始写程序的年轻人的劲头,这让我挺触动的。

今天,很多人都在担心未来的工作会变成什么样。但在 builder 这个群体里,你看不到半点偏执与恐惧,你看到的全是对未来的兴奋。这就是我如此热爱 Supabase 的原因,它让那些原本只是普通蓝领或传统行业从业者的人,突然解锁了一项不可思议的创造力,在自己的生活里长出了真正的创业精神。

02

Markdown 不够用了,

Personal Agent 需要 Personal Database

Jared Friedman(YC):回顾数据库的发展史,会发现一个非常强烈的反差。在过去几十年里,全世界只有相对少数的大型企业才拥有并运行着庞大的数据库。

我记得 2020 年 Supabase 刚进 YC 时,你们提出过一个愿景,「让每个人都能极其轻松地创建一个数据库」。

老实说,在 AI 出现之前,这个想法听起来几乎是不合逻辑的。那时候根本不存在所谓的「个人数据库市场」,如果有人说「我要做一家直接面向消费者的数据库公司」,听起来简直就像一句语法错误。因为对绝大多数普通人来说,如果你不会写代码,给你一个数据库又能干什么呢?

但今天,你们不仅服务着早期创业公司,还在直接服务海量普通消费者。或者更准确地说,服务着他们的 Personal Agent。

Paul Copplestone:完全正确。这些个人用户的数据库,大概不会像创业公司那样一路做大,但他们很可能会用一辈子。因为这个数据库背后跑着的,是他们的个人财务软件、健康应用,甚至是他们自己的小生意。

人会成长,信息会越攒越多,数据库里存的东西也会跟着变多。某种程度上,这就是我们自己增长的一个指数。对我们来说,Prosumer(专业消费者)市场是一个很好的增长方向。

Jared Friedman(YC):Harj,你最近一直在给自己写这类 Personal Software,底层也都跑在 Supabase 上,能聊聊吗?

Harj Taggar(YC):我做的是典型的 N-of-1 软件,也就是只服务我自己一个人的软件。起因是前阵子我对 OpenClaw 上瘾了。

说来有点不好意思,大概六个月前,我还公开说过,以后不需要 UI 了,所有交互都会在聊天里完成。我也一直不想用数据库,想把所有东西都放在 Markdown 里。

但现实很快结结实实地打了我的脸。当你真正重度用下去就会发现,到了某个临界点,你不仅必须要有一个真正的数据库,而且依然需要直观的 UI。

过去几周,我在 Supabase 上给自己搭了一套系统,叫 Control Tower,把生活的各个部分都放了进去:有一个界面帮我分拣邮件,不用再去翻收件箱;有财务和支出记录;有体重、训练这些健康数据。所有东西都在一个地方。

只看个人财务这一块,我觉得它至少已经能和 Mint、Monarch 这些消费级产品做到功能相当,有些地方甚至更好用,因为它可以充分利用只属于我的上下文。

比如,当我的信用卡账单里出现一笔陌生的个人转账时,传统的记账软件根本不知道这笔钱是干嘛的。但我自己的系统会自动去我的 GBrain(个人知识库)里检索这个收款人的名字,结合我过往的邮件和聊天记录,搞清楚这个人是谁,再把交易准确归类。

以前,光是做「交易自动识别与分类」就能养活好几家创业公司。现在,我完全可以只为自己做一个,不用考虑它能不能服务所有人,也不用听别人的意见。

Paul Copplestone:我们看到最多的就是财务和健康的用例。这两个领域里,人们尤其想拥有自己的数据。

很多人在做的一件事,是把自己所有随身设备产生的数据,实时同步进同一个个人的 Supabase 数据库里。这是一项堪称魔法的能力,因为一旦你把分散在不同角落的数据汇合到同一个库里,你就可以直接用自然语言发号施令,让 Agent 在看似毫不相干的数据之间找关联。

Harj Taggar(YC):对,关联才是最有价值的。我还拿健康举例,我的体重和训练数据都在 Supabase 里,跑在上面的 Agent 同时能看到我的日历。它看到我最近体重涨了,也知道我那段时间在出差,就会跟我说没事,下周回到正常节奏就行。这种上下文很有价值,单个 App 是给不了的。

Paul Copplestone:而且我开始重度用 Personal Agent 之后,有点担心自己的工作习惯、日常流程和 CRM 全都被锁在某一个特定的 Agent 里。

试想一下,如果哪天市面上出了一个更聪明的新 Agent,或者我想同时用好几个不同的 Agent,核心数据却被锁死在某一家公司的 Agent 内部,我就会彻底丧失主动权。

所以我正慢慢把这些数据抽出来,放进一个完全独立的个人 Supabase 数据库里。这样一来,底层的个人数据库牢牢攥在我自己手里。至于上层,今天我想挂载哪个 Agent、明天想换哪个新模型,全都可以随时自由插拔。

Jared Friedman(YC):这也是你们的价值所在。真正有价值的是底层的数据库,它是 Store of Record(记录系统)。

你应该拥有自己的数据库,再把各种应用和 Agent 搭在上面,而不是把自己的所有数据都放在别人的数据库里。

一年前,如果有人问我需不需要一个「个人数据库」,我肯定觉得莫名其妙。但站在今天看,拥有一个装满自己人生全部数据的 Personal Database,反而是整个 AI 时代最核心、最有价值的事。

03

如果每人都有一个数据库,

Infra 也得跟着变

Jared Friedman(YC):假如将来世界上每个人都有一个自己的 Supabase 数据库,里面存着健康、财务、人际关系这些数据。你们的服务对象从「创业公司」变成「全人类」,这个规模相当于放大了 1000 万倍。底层架构要怎么接住?

Paul Copplestone:我们现在每周新建 100 万个数据库,看起来已经很多了。但你看 ChatGPT,他们最新披露的周活跃用户大约是 12 亿人。假设未来这 12 亿人手里的 Personal Agent 每个月哪怕只发起一个新项目或新建一个个人库,那就是每月 12 亿个数据库。

我们必须朝这个规模去设计架构,这是数据库行业过去从未面对过的问题。

Jared Friedman(YC):仅靠标准的 Postgres(Supabase 底层采用的开源数据库)能支撑这种数量级吗?还是得自己造一个数据库引擎?

Paul Copplestone:如果 AWS 愿意给我们打个骨折价,说不定还能硬扛。但现在全世界都在疯抢算力,而且很多轻量工作负载未必需要一辆「法拉利」。

我们最近收购了 Turso。它拥有一套极其精妙的底层架构,既能与 Postgres 生态兼容,同时底层又原生兼容 SQLite。我认为 SQLite 是计算机历史上最了不起的数据库设计之一。基于 Turso 的技术,我们将提供一个叫 Supabase Spark 的全新轻量级产品层,专门用来承接刚刚起步的轻量工作负载。

在另一端,如果某个个人项目后来长成了一家真正的巨型企业,数据量一路膨胀到 PB 级别,我们原有的企业级多实例架构也能无缝接住。我们的说法是,「从原型到 PB」。

Jared Friedman(YC):在 AI 时代之前,数据库行业的传统认知是,要想赚钱、成为下一个 Oracle,就必须尽快放弃小散户,全力攻下大型企业市场。但你们现在发力 SQLite 和个人端,相当于在往完全相反的方向狂奔。

Paul Copplestone:同时往两端跑极其痛苦,但我们两边都要拿下来。Multi-Postgres 负责向上服务到 PB 级企业,Turso(Supabase Spark)向下把个人端和原型端的门槛降到极致。

因为数据库生意最底层的商业规律从来没变过。我听过一个数据,AWS 大约 40% 的营收来自那些从 Day 1 就长在 AWS 上、随后一路长大的客户。说服任何人迁移数据库几乎是不可能的任务,所以你只需要做对一件事,永远出现在用户起步的 Day 1,让他们用得极其爽快,从此再也不想离开。

04

不需要 Dashboard 了,

现在是 Make Something Agents Want

Garry Tan(YC):每位创始人进 YC 第一天都会拿到一件写着「Make something people want」的 T 恤。但我们越来越意识到,今天也许应该说「Make something agents want」。

Supabase 大约 70% 的新增活动来自 Agent,这很夸张吧?当主要使用者从「人类」变成了「Agent」,你们对自己的产品和团队做了哪些改造?

Paul Copplestone:非常疯狂。尤其是今年,我们在数字上看到一个非常明显的拐点,使用方式正在大幅转向 Agent。

Supabase 大致经历了三个阶段。最早我们是一家 Dashboard 公司,后来变成 API 公司,现在又成了一家 Code-First 公司。

刚进入 YC 时,我们发现哪怕是对开发者来说,数据库也很难用。于是我们模仿 Airtable 的交互,在 Postgres 之上做了一层极其好用的可视化 Dashboard 面板。

后来,有集成伙伴提出需要批量自动创建数据库,我们顺势把整套建库与管理能力全部 API 化。事实证明,这个决定正好接住了 2024 年 Bolt、Lovable 等一波 AI 应用生成平台的爆发。

今年我发现,已经没有人再来访问我们的 Dashboard 了。既然人类不再打开网页点按钮,那谁在用我们的产品?是 Coding Agent 和 Personal Agent。

哪怕表面上我们说「在为习惯代码优先的人类服务」,实际上很快人类连代码界面都不会再碰了,交互的另一端 100% 是 Agent。Agent 最喜欢用什么模态干活?它们最爱 CLI 和纯代码。

于是,我给团队写了一份产品备忘录,Supabase 必须全面转向 Code-First 和 Git-Native。Dashboard 上有的功能,代码里必须同步做到,本质上就是 Infrastructure as Code。为此,我们重构了底层的 CLI 和工具链,确保它们能在各类代码沙盒环境里被 Agent 丝滑调用。

Garry Tan(YC):你们还做了一个非常精妙,但市面上绝大多数开发者工具都没意识到的改造,重写 Error Messages(报错信息),这是怎么想到的?

Paul Copplestone:赢得 Agent 分两步。

第一,让大模型在第一时间选中你。我们在这件事上受益很大,赶上了一个好时机,成了 LLM 推荐数据库时的默认选项。开源也很关键,Agent 极度讨厌撞上闭源黑盒的高墙。开源让 Agent 在遇到问题时能直接去翻底层源码,同时也满足了大型企业对代码安全审计的硬性要求。

第二,当 Agent 在使用你的产品卡壳时,千万别让它放弃并切到竞品去。

Agent 肯定会在某个环节卡住。以前写给人类程序员看的报错信息通常极其敷衍,比如直接抛一个 500 Internal Server Error 或者一句天书般的简短报错,人类程序员看到后自己去 Google 搜索解决方案。但在 Agent 时代,核心目标是让 Agent 能够「自我修复」。

所以我们把 Supabase 所有的报错信息翻出来重做了一遍。当系统报错时,我们直接在 Error Message 的返回文本里,手把手告诉 Agent,你为什么会触发这个错误、你现在应该执行哪条具体指令来修复它、或者你应该去读取哪个 URL 下的文档来解决它。

我们工程团队会挑出一个用例,比如「我要做一个应用」,然后反复循环,不断改进自己的报错信息,直到几乎任何需求都能一次做成。

这其实不复杂。现在的模型已经足够聪明,很多事自己就能搞定。但以前只为人类开发者设计的很多东西,确实得为 Agent 重新做一遍。

Jared Friedman(YC):你们会专门让 Agent 来测试产品吗?比如让它们用 Supabase 做东西,再把卡住的地方报告出来?

Paul Copplestone:不仅在做,这已经成了我们最核心的工程日常。

我们搭建了一个公开的 Evals 评测网站,实时测试并展示市面上所有主流大模型在构建应用时的真实表现。同时我们在内部维护着一整套严密的 Eval 测试集,专门评测哪些模型原生操作 Postgres 的能力最强,并针对模型的知识盲区编写专门的 Skills 喂给它们。

现在我们很大一部分工程研发精力,已经从做功能转到了测试具体用例上。我们会去想人们是怎么构建的,再围绕这些场景做测试集。

05

选一个能活 50 年的品类,

做适应变化最快的公司

Garry Tan(YC):你们前阵子在内部做过一次调查。半年前,只有 10% 的工程师会让 Coding Agent 写自己 80% 以上的代码,现在这个比例到了 60%。这半年发生了什么?

Paul Copplestone:公司内部没有任何自上而下的强制 AI 政策。我们只是彻底放开权限,不管工程师想用什么前沿工具,公司全部买单。

人是需要被说服的,工程师尤其如此。年初的时候,模型已经挺好用了,之后又变得更强。大家也开始看到,用这些模型真的能做成很厉害的事。

所以内部的使用量涨得很快,而且大家做的东西不是那种随手 vibe coding 出来的,难度都很高。转向 AI 写代码之后,我们做的测试和引入的测试工具也多了很多,这样才能确认最后交付的东西是好的。

Harj Taggar(YC):Supabase 几乎稳稳接住了从移动互联网尾部、到如今 Coding Agent 和 Personal Agent 的每一个拐点。下一次变化出现时,你们会怎样做得更好?

Paul Copplestone:第一,选一个耐久的品类。有个东西能让我睡得安稳,就是林迪效应(指一样东西存在得越久,就越可能继续存在下去)。

数据库已经存在了 50 年,我确信它还会再存在 50 年。不管 AI 最后走到哪一步,世界依然需要数据库。如果你打算把整个人生押在一家创业公司上,一定要选一个经得起时间冲刷的底层品类。

第二,变化太快了,我们不指望在 Supabase 内部拥有所有答案,只求做适应最快的那一家。我观察过很多自己喜欢的开发者工具,它们一开始都专注开发者,后来往上走,变得越来越像大公司,慢慢停滞,也失去了原来那份喜爱。

相比之下,像 Stripe 这样的公司之所以不一样,是因为创始人始终对「新一代人正在用什么新方式造东西」保持着偏执的敏锐。如果你是为下一波浪潮在做产品,就得始终留一只眼睛看着接下来会发生什么,而现在这个时间窗已经很短了。保持适应能力,确保团队有余力快速转向,是我们明年的重点。

第三,Dogfooding(内部试用)非常重要。我会一直拿各种新工具来用我们自己的产品,看看缺口在哪里。没有什么反馈,比自己被自家工具卡住更直接。

也要给团队留出容量。我们会在团队里留出一部分人手,专门用来和生态里最前沿的头部玩家一起做联合实验。这样他们有想法时,我们就能马上试一试。

大部分尝试其实不会成功。哪怕一开始双方都觉得是件很酷的新事,我们也不知道结果会怎样,试下来很多都失败了。但只要有一两个赌对了,就足以让我们和合作伙伴一起,赶上下一轮超级浪潮。

更多阅读

AI 让产品越来越容易做,然后呢?

独家 | Genspark 发布第二款硬件 VoicePad:在用户本来就要开口的地方,放一个 AI 入口

10 月,我们推荐这 20 位独立开发者,和他们的 100 款产品

Manus 内部复盘:一家 Agent 公司,如何先用 Agent 改造自己?

跳转微信打开

来源:Founder Park · 微信公众号 · mp.weixin.qq.com