一周建一百万数据库，Supabase在给Agent做后台

Supabase 现在是 AI 编程时代的默认后端之一。这个说法来自 Y Combinator 的推文，数字也够硬：1300 万用户，每周新建超过 100 万个数据库，约 70% 的新增活动来自 agent。视频里还有一句背景：Supabase 管理的数据库超过 5000 万个，收入涨了 4 倍。

对不写代码的读者，先补一句。Supabase 是开源 Postgres 平台，把数据库、登录、存储、API 这些后端能力打包。过去这些活由开发者手写，现在越来越多由 agent 调用工具完成。agent 可以理解成会自己读代码、改数据库、跑命令的 AI 程序。

Y Combinator 的 Lightcone 请来 Supabase 联合创始人兼 CEO Paul Copplestone。访谈里提到 Supabase 的三个阶段，也聊到 builders 和传统开发者的区别。更关键的一句判断：个人软件可能会像个人文档一样常见。对应到数据层，就是个人数据库和数据所有权。

评论区比访谈更直接。有网友把 Supabase 接进 agent，修掉了 feednest 的一批慢查询。也有人问，agent 会抱怨拿到的 schema 吗，还是这仍然是人要做的事。这个问题下面出现了几条技术提醒。

有网友说，默认值比文档重要。agent 容易跳过 RLS，除非模板强制。RLS 是 Postgres 的行级安全，表暴露出去又没开 RLS，可能对已授权角色敞开。另一位网友补了操作细节：agent 跑完原始 CREATE TABLE 后，需要 ENABLE ROW LEVEL SECURITY。

迁移也是坑。Supabase 有 apply_migration 写受跟踪的迁移，branches 可以重放 list_migrations。漏洞在 execute_sql。agent 用它临时修一下，问题看起来解决了，但不会变成迁移。下一个分支就没有这次修改。有网友把它类比成 JPA 的 ddl-auto=update：一个能跑的 schema，不代表一个能重放的 schema。

还有两件小事被反复提到。agent 任务结束很少删数据库，闲置项目会堆起来。错误信息现在也像给 LLM 看的 onboarding，清晰的报错能让 agent 自己往下走。有人调侃，70% 的新增活动来自 agent，剩下 30% 是人在问 agent 迁移为什么失败。

一周建一百万数据库，听起来像基础设施的胜利。评论区有人补刀：总有一个应用会迎来第二个用户。这个笑话不轻，它点出个人软件和 agent 生成应用的现实：创建变便宜，维护和权限不会自动变便宜。Supabase 在做的事，是把默认 schema、错误信息、迁移工具这些入口重新设计给 agent。落地页对 agent 没用，默认值才是产品。

原推：https://x.com/ycombinator/status/2116176659795825035

YouTube：https://youtu.be/vl7HiMdGfjo