先看证据
问题不在建表，而在后端状态藏在哪里
Supabase 联合创始人 Paul Copplestone 与 Ant Wilson 在 2026 年 10 月 28 日发布的访谈中，讨论了 AI 编程代理为何常用 Supabase，以及后端如何适应代理生成应用的工作流。Supabase 是以 Postgres 为核心的后端平台，这场讨论面向的不是模型怎样写出一段 SQL，而是代理怎样把一个应用从代码推进到可运行、可维护的状态。
旧流程里，代理主要在代码仓库工作，后端配置却可能留在仪表盘：建表、调整 RLS 策略，再通过 CLI 把变化整理成迁移文件。代码与实际后端因此容易脱节，代理也难以仅凭仓库判断系统当前是什么状态。Supabase这次的变化，试图把这类隐性状态重新变成软件工程流程里可见的材料。
把目标状态交给仓库，而不是让代理猜历史
Supabase现在推动用 SQL 文件描述期望的数据库 schema，并把项目设置放进 config.toml。代理可以像读应用代码一样检查和修改这些文件；随后由 pg-delta 比较目标状态与迁移历史，生成 SQL migration。重点不是让代理更熟练地手写迁移，而是让它先表达最终想要的结构，再由工具把这个目标转换为变更步骤。
这改变了后端变更的审查入口。工程师不必只从一串历史迁移反推数据库现在是什么样，代理也能在同一个仓库里提出 schema 修改，供代码评审和测试。但声明式描述并不等于迁移天然安全：官方文档指出，列重命名可能被处理成删除旧列、再新增新列。pg-delta不负责普通表数据的增删改，也不负责生产环境的零停机发布编排，因此高风险变更仍需要人检查和安排。
环境和运行时也必须进入同一条工作流
仓库可读只是第一步。代理反复创建、测试环境时，本地依赖和配置的成本会比人类开发者偶尔搭环境更频繁地出现。Supabase推出的本地 runtime 可在没有 Docker daemon 的机器上运行，也支持按目录启动多个本地实例，让不同代码分支能够各自测试；不过发布时它仍是 alpha，并且默认关闭，不能当作已经普遍可用的基础能力。
应用能建起来，还需要地方执行较长的工作。Supabase Compute计划提供与数据库处于同一项目的长期运行环境，可用于 agents、embedding 等任务，并提供完整 Linux 环境，支持通过 CLI 或 Management API 部署。它试图减少另配服务、维护连接并把上下文交代给代理的工作，但发布时处于 private alpha。Edge functions仍有用途，只是不能覆盖所有长时负载；Compute能否成为可靠的生产选择，材料尚不足以判断。
能操作还不够，代理得知道发生了什么
能执行 SQL，不代表代理知道自己改动了什么、应用如何使用数据库，或失败发生在哪里。Supabase把 Operate 相关能力与 Build 放在一起看，宣布让代理访问项目日志，并通过数据库查询和 notebook 观察项目，同时提供权限控制。用户自己的代理也可通过应用 MCP server，以已登录用户身份访问该应用授权的数据。这些能力试图补上从修改到排障之间的上下文缺口。
这也是后端对代理开放时必须正视的边界：访问能力应与授权范围相连，排障信息也要足以判断操作结果。材料说明了权限控制和用户身份这类设计方向，但没有给出更完整的权限模型、审计细节或故障处理保证。技术负责人应把它们看成平台正在构建的操作接口，而不是默认代理已经拥有安全、完整的生产运维能力。
小数据库的数量和大客户的规模是两道题
Supabase创始人在访谈中称，公司每月启动约 500 万个数据库；另一个口径是公司 2026 年 10 月的 Turso 收购公告称每周超过 100 万个。两者量级相近，但公开材料没有说明统计定义和时间窗口是否一致，不能当作精确换算。公司 2026 年 6 月还称数据库启动量同比增长 600%，并表示新启动数据库中超过 60%由某种 AI 工具启动；这些是公司自报数据，分类与测量方法没有进一步披露。
这些数字解释了为什么“代理友好”最终会碰到扩容问题，但扩容并非单一任务：承接大量新建的小数据库，与支撑客户逐渐变大的数据库，需要不同的工程处理。Supabase在 Scale 方向提到 OrioleDB、Multigres 和收购 Turso，访谈也把可靠性与纵向、横向扩展放进“prototype to petabyte”的叙事。主持人关于 frontier 模型几乎一致优先推荐 Supabase 的观察，则来自其个人追踪器，缺少公开样本和评估方法，不能据此断言代理普遍偏好。对团队而言，可执行的判断是先利用仓库化 schema 改善可审查性，同时把 alpha 能力和危险迁移纳入明确的人审门槛，等运行时成熟、指标口径清楚后再扩大自动化范围。