规模信号：从三成到八成，Agent 成为建库主力
这轮重构最硬的证据来自平台方的一手披露。把可交叉验证的数字排成时间线：
| 时间 | 主体 | 数据点 | 口径说明 |
|---|---|---|---|
| 2025 年 5 月 | Neon（被 Databricks 收购） | AI 创建库占比从 30% 升至 80% | Databricks 新闻稿口径；另有媒体指出这些库偏短命实验而非生产负载 |
| 2025 年 5 月 | Databricks / Neon | 收购价约 10 亿美元 | CNBC 转引口径 |
| 2026 年 2 月 | Databricks | Lakebase（基于 Neon 架构）在 AWS 正式可用 | Databricks 公告 |
| 2026 年 6 月 | Supabase | 建库量同比增长 600%；新库约 60% 来自 AI 工具 | Supabase Series F 披露口径 |
| 2026 年 10 月 | Supabase | 每周建库超 100 万、月增约 400 万，新库约 70% 来自 Agent 或 AI 工具 | Supabase 10 月 2 日公告口径 |
两组数字的斜率值得注意：Neon 的 AI 占比一年内从三成爬到八成；Supabase 从 6 月的六成爬到 10 月的七成，同期的绝对量是月增 400 万库。morningtick 的分析还补充了一个容易被忽略的细节：据 6 月的报道，Anthropic 的 Claude Code 是 2026 年初以来平台上新建库的单一来源中占比可观的一项——增长与个别编码智能体产品直接挂钩，而非均匀来自「AI 泛潮」。
必须标注的是：以上全部为厂商自报口径，Supabase 与 Neon 均未同步披露这些库的留存率、付费转化率与生产负载占比。「Agent 建的库」里有多少是一次性原型、用完即弃，直接决定这组增长数字的商业含金量——morningtick 的判断是：一个被建出又被抛弃的原型库是服务成本而非客户。
Supabase 与 Turso：文件级轻量库的第二引擎
10 月 2 日的公告是本轮信号密度点：Supabase 获 1.5 亿美元新融资（GIC 领投，CapitalG、IronArc、SquarePeg 跟投），并收购数据库公司 Turso。Verdict 的报道厘清了资金口径：这距离 6 月的 5 亿美元 F 轮（投后 105 亿美元）仅四个月，新估值 106.5 亿美元只比上轮高约 2%，美国证监会 9 月的 Form D 文件指向这是同一轮的延展而非新定价——部分资金用于员工流动性。收购金额未披露，融资额不等于收购价，quasa 的分析特别提醒不要把两个数字混为一谈。
Turso 带来的技术资产是一条与 Postgres 互补的第二引擎路线：用 Rust 从零重写 SQLite 作为开源项目，移除了原版单写入者的限制以适配服务器负载，云服务采用 diskless 架构——写前日志（WAL）落在对象存储上，数据库按需加载、空闲挂起。结果是一台服务器可以托管数百万个小库，每个库的创建成本接近文件拷贝。BlockBeats 快讯将其概括为「让每个 Agent 都能随手开数据库」。Turso 创始人 Glauber Costa 将出任 Supabase 的 Head of Agentic Services，他与联合创始人 Pekka Enberg 带团队整体加入；Turso 服务继续运行、代码库保持开源。Costa 在收购声明中写下了他的目标刻度：「从一开始，我的目标就是为客户提供十亿量级的数据库。」
产品蓝图是两段式：智能体任务先落在轻量的 SQLite 系引擎上，应用长大后经由 Supabase 生态升档到 Postgres。Superhuman、CTO.new、Sauna.ai、Mastra 等团队被点名为已经在「每 Agent 一库」形态上运行的客户。quasa 同时指出了蓝图的空白处：从 Turso 库升档到 Supabase Postgres 的具体迁移工作流与兼容性承诺尚未发布——两个系统「方向上要打通」与「已经打通」之间还有产品距离。
三种隔离原语：同一假设的三条工程路径
墨天轮的行业分析给出了一个有效的整理框架：2026 年 9 月底到 10 月初不到三周内，三家厂商在各自独立的工程路径上做出了同一个判断——Agent 时代的产品必须按「每 Agent 一库」重新设计。三家对应三种隔离原语：
| 厂商与产品动作 | 隔离原语 | 工程取舍 |
|---|---|---|
| Supabase + Turso（10 月 2 日） | 独立引擎：每个 Agent 出生即获一个 SQLite 系文件库 | 文件即数据库，无进程无端口；WAL 上对象存储、按需加载；业务沉淀后升档 Postgres |
| Cockroach Labs（同期推出 Continuum） | 共享引擎：数千虚拟集群池化到共享主机，引擎内租户键空间隔离 | 无跨方言问题，但角色、授权、行级安全等治理能力仍要在共享引擎上实现 |
| Google Cloud（AlloyDB 预览） | 共享存储 + 一次性计算节点：每个 Agent 挂独立只读 Postgres 节点 | 写入被排除在 Agent 之外，所有变更走上层受控写路径；本质是读写分离做到 Agent 维度 |
口径标注：Cockroach Continuum 与 AlloyDB 每 Agent 只读节点的细节目前主要来自墨天轮的单篇行业分析转述，两家厂商官方公告的完整产品文档本站尚未直接核验，引用时应以官方文档为准。但「三条路径、一个假设」的框架本身有价值：Agent 时代的并发形态不是单库负载变大，而是库数量变多——这决定了隔离单位从「租户」下沉到「智能体」。
经济学：为什么「每库一台服务器」撑不住了
Agent 时代数据库的核心矛盾不是单库变大，而是库的数量爆炸：当建库主体从人变成智能体，隔离单位就要从「租户」下沉到「智能体」，计价单位就要从「每库常驻」变成「每库按需」——三种隔离原语都是这个矛盾的不同工程解。
把三种原语放回同一个成本问题：传统托管数据库按「一个库 + 一组常驻资源」计价，当智能体以毫秒级频率创建用完即弃的原型库时，这个模型在库还没有创建时就破产了。Supabase 自己的产品形态（每个项目一个专用 Postgres）正是被自己平台上 Agent 建库潮冲击的对象——这正是它收购第二引擎的逻辑。
轻量化路线的成本结构：Turso 系架构下，空闲库近乎零成本挂起，长尾的废弃库从「运维负担」变成「期权」——某个被抛弃的原型可能长成真正的应用，而保留它的成本接近于零。Draxlr 的对比分析补充了另一侧的实践参考：Neon 的 scale-to-zero 与 100 个免费项目额度让短命数据库的闲置成本接近免费，而需要登录、存储、鉴权的完整应用则适合 Supabase 的一体化后端。
隔离同时是安全边界。morningtick 的分析点明了这层逻辑：给每个智能体独立的存储而非共享 schema，限制了失控或被攻陷智能体能触及的爆炸半径——这与智能体安全领域的最小权限原则同构。对要把智能体接入生产系统的团队来说，「每 Agent 一库」不只是资源模型，也是纵深防御的一层。
Andy Pavlo 的十个判断：10 到 100 倍查询量
如果平台方的数字描绘的是「库的数量」，CMU 数据库教授、今夏加入 ClickHouse 创建 ClickHouse Labs 的 Andy Pavlo 在与 Matt Turck 的播客对谈中把视角拉到「查询的量级」。节目披露的核心观点：
- 10 到 100 倍查询量：智能体成为数据库主要使用者后，查询总量可能比人类开发者时代高一到两个数量级——访问模式、护栏与成本模型都是为人类开发者设计的，这套设计正在过时。
- 60% 的开源数据库已有 AI 提交：开放源码数据库项目中，已有约六成出现来自编码智能体的 commit——智能体不仅用数据库，也开始改数据库。
- Text-to-SQL 从 60% 到 99.5%：自然语言到 SQL 的准确率跃迁让「直接问库」成为智能体的默认技能。
- 智能体会删生产库：节目用专门段落讨论智能体误删生产数据库的现象，并给出护栏设计的「幼儿上楼梯」规则——按对待幼儿上楼梯的方式对待智能体的写权限。
- 记忆的载体之争：智能体记忆放文件还是放数据库，「一切皆数据库」与「一切皆文件」两条路线各有拥趸。
- 「它把我引回我自己」：模型推荐数据库的机制被类比为新型 SEO——训练语料的循环引用让推荐结果的可信度需要单独审视。
口径标注：以上为播客对谈中的观点表达，属于专家判断而非审计数据；其中 Neon 80% 一节 Pavlo 自己也做了口径讨论（「智能体创建的库」的统计标准）。另外按节目披露，Matt Turck 所在的 FirstMark 是 ClickHouse 的投资方——利益关联已标注。
治理风险：删除生产库与「幼儿上楼梯」规则
把规模数据与专家判断合起来看，行业真实面对的不是「要不要给智能体接数据库」，而是「接多大的权限」。三条已经反复出现的教训：
- 写权限默认收走：Google AlloyDB 的每 Agent 只读节点代表了一种趋保守的工程共识——智能体读一切、写路径收归上层受控管道。这与 R-INDUSTRY-04 记录的智能体安全危机（91% 生产级 Agent 存在漏洞）互为印证。
- 生命周期要自动化：按需创建的库需要配套的自动回收，否则「百万级库存库」会在计费与合规两侧同时爆掉；scale-to-zero 与文件级挂起是成本解，标签与 TTL 是治理解。
- 成本归因要按 Agent 维度记账：当建库主体从人变成智能体，FinOps 的归因粒度也得下沉——哪个智能体、哪个任务、哪次实验花的钱，混在项目账单里就失去了管控抓手。
对智能体团队的启示与观察点
对正在把智能体接入生产数据的团队，本轮行业动向给出三层可操作的启示：
- 把「库的创建成本」纳入智能体架构评审：一个每天创建几百个原型库的智能体管线，在传统托管库与文件级轻量库上的成本可能差出量级——选型时按智能体的建库频率而不是数据量来算账。
- 隔离原语决定安全上限：独立引擎、共享引擎、共享存储三种原语的治理能力差异，应映射为智能体权限矩阵的差异——能写、只读、写走受控管道，分别对应不同的库形态。
- 警惕「增长数字」的幸存者偏差：80%、70% 这类占比说的是创建量，不是价值量。评估基础设施押注时，留存率与付费转化率是比建库增速更有信息量的指标——目前两家厂商均未披露。
三个值得跟踪的观察点：其一，Supabase 与 Turso 的升档路径（Turso 库到 Postgres 的迁移工作流）何时落地，它决定「两段式」蓝图是产品还是叙事；其二，Cockroach 与 Google 的「每 Agent 一库」形态是否会进入正式可用版本并公布独立成本数据；其三，Databricks Lakebase 在被收购一年多后是否延续 Neon 的 Agent 建库增长曲线——如果 Lakebase 的 AI 建库占比显著回落，说明 80% 更接近套利期现象而非稳态。目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。