Agent 数据库入口之争，Supabase已行动
P
digoal约 4 分钟
digoal约 4 分钟那 SQLite 为什么合适？因为 SQLite 的本质是一个文件格式，不是 Server Process。一个库就是一个文件，创建就是写个文件，删除就是删个文件，闲置成本几乎为零。但原版 SQLite 有个硬伤，单写者限制，而且它当初设计就没考虑过服务器侧的大规模调度。Turso 做的事，就是用 Rust 从底层重写了一遍，搞出了 MVCC，现在多写者也能跑了，然后套了一个无盘的、WAL on S3 的架构，让一台服务器能挂载和管理数百万个库，用的时候加载，不用的时候挂起。你把这个能力和 Agent 的需求对一下，严丝合缝。Agent 要的就是“像建个文件一样建个库”，Turso 给的恰恰就是这个。
那 Supabase 图什么？它图的不是把 Postgres 换掉，它图的是入口。逻辑是这样的：如果未来的软件生产主体是 Agent，那 Agent 在写代码、跑测试、做原型的时候，数据层应该首选什么产品？如果 Supabase 只有 Postgres，那 Agent 在那些碎片的、临时的、不值当开一个正式实例的场景里，就流到别家去了。Supabase 要的是，Agent 一开始随手建的那个库，就是 Supabase 生态里的。先用 Turso 的 SQLite 跑着，便宜、快、零摩擦；等这个原型活下来了，变成正经应用了，需要多用户、复杂查询、行级安全、连接池了，你再顺着一条平滑的路径升级到 Supabase 的 Postgres 上去。这个熟称“毕业路径”。你只要把入口占住了，后面的升级转化就是自然而然的事。反过来，如果你入口没占住，Agent 一开始就用别人的东西，等它长大了你再去抢，成本高十倍。这就跟国产数据库现在去迁移 Oracle 一个道理。
再往深一层，这其实是在重构数据库的计费单元和部署单元。传统云数据库是按实例算的，你开一个实例，哪怕空跑，钱也在烧。Turso 的架构把单元压到了单个数据库，单机百万库，闲置不耗资源。这意味着 Supabase 可以给每一个 Agent 会话、每一个 CI 分支、每一个预览环境都发一个专属数据库，不需要跟别人共享 schema，不需要靠表前缀去隔离，用完直接扔。这种隔离性是共享测试库永远给不了的。而且你注意，Glauber Costa 加入 Supabase 之后的头衔是 Head of Agentic Services，这个头衔本身就说明，Supabase 把 Agent 当成一个独立的客户群体来服务了，不是给人类开发者加个功能，是给 Agent 建一条专门的产品线。
当然，现在距离目标还有一些GAP。第一，那条“从 SQLite 平滑升级到 Postgres”的“毕业”路径，目前只是方向性的承诺，官方博客里就一句话，没有工具、没有时间表、没有说数据怎么迁、schema 怎么转、应用代码要不要改。这个路径如果做不顺，那入口占住了也转化不了，Agent 的原型在 SQLite 上跑到一定复杂度，发现升不上去，那就尴尬了。第二，Turso 自己覆盖了 SQLite 大概 97% 的特性，但 schema 变更那块据说还落后。Agent 跑迁移脚本是高频操作，这块如果卡住，体验会出问题。第三，价格。Turso 那边是 4.99 美元无限库的玩法，Supabase 这边是按项目按计算资源算的，两套计费模型差得很远。收购之后 Turso 的定价会不会变，官方没说，只说现有用户照旧。但长期看，两套账本要并到一个公司里，不可能永远各算各的。
不过话说回来，这些GAP不会影响战略推演的大方向。Supabase 这步棋的底层判断是：数据库的下一个增量客户不是人，是 Agent。人类开发者一年建几个库，Agent 一天建几百个。谁能让 Agent 以最低的摩擦、最低的成本、最自然的路径把库建起来，谁就握住了下一个十年的入口。Postgres 是目的地，但 SQLite 是入口。买 Turso，买的就是那个入口的钥匙。至于这把钥匙能不能顺利打开门，把流量引到 Postgres 那个厅里去，就看 Glauber 团队后面把那条“毕业”路径铺得有多平了。