如果你最近在做带智能体的产品，大概已经碰到过这个问题：任务跑起来了，状态往哪放？
十月二日，Supabase 一次宣布了两件事——一笔融资，和一起收购。它瞄准的正是这个位置。
三件事一起宣布，别混着看
先把事实摆清楚，这类消息最容易把三件事糊成一团：
- 融资：Supabase 完成一笔一亿五千万美元的融资，由新加坡主权基金 GIC 领投，跟投方里有 Alphabet 旗下的成长基金 CapitalG、IronArc 和 SquarePeg。此轮估值约一百零六亿五千万美元。
- 收购：公司已同意收购数据库创业公司 Turso，收购对价未披露。
- 新产品：同步推出面向长时间运行的智能体的托管服务 Supabase Compute。
最容易误读的是钱数：融资额不等于收购价。 这是两笔独立的账，公告里明确没说 Turso 卖了多少钱，也没给交割日期和条件。还有一层容易漏——这笔融资距上一轮（六月，五亿美元，投前估值一百零五亿美元）只隔了四个月，估值涨了不到两个百分点，且公告说这笔钱有一部分用于员工老股套现。所以它更像是同一轮融资的延展，而不是一次大幅抬价。
Turso 做的事：把 SQLite 用 Rust 重写一遍
要理解这笔收购，得先知道 Turso 到底解决了什么。
SQLite 是老牌的单文件数据库，优点是轻、开箱即用；短板也出名——写操作是排他的。一个写事务没提交，其它写请求全在排队。做单机应用够用，一上服务端并发就不行。
Turso 的做法不是给 SQLite 打补丁，而是用 Rust 从零重写，同时保持文件格式、SQL 方言和接口兼容：现有的数据库文件直接打开就能用，一条 SQL 都不用改。重写之后补上了几样原本没有的东西——多版本并发控制、变更追踪、向量检索，以及一个内置的 MCP 服务，让编码助手可以自己查表结构、跑查询。
云端那一侧更关键：它把预写日志放到对象存储上，做成了无盘架构，单台服务器能管理上百万个数据库，需要时加载、闲置时挂起。用官方的话说，数据库被当成一个轻量文件，而不是一个常驻的服务器进程。
为什么值得为「一个 Agent 一个数据库」花钱
传统的后端是「一个应用一个（或一小组）数据库」，常驻、有连接池、按月付钱。智能体的用法不一样：它可能接过一个任务，建一套执行环境、抓数据、存中间结果、调工具，干完就结束。给这种一次性的活儿配一台常驻数据库机器，成本在活儿开始之前就已经不划算了。
Supabase 把目标写得很直白：建一个数据库，应该像建一个文件一样容易，成本也差不多不用考虑。 对小负载，不该每次都去开一台专门机器；数据库该是随建随用、便宜、留一条通往生产的清晰路径。
后半句才是这家公司的真实算盘：先用 SQLite 形状的轻量库把项目接住，等应用长大、撑不住了，再迁到它的 Postgres 平台上——用最便宜的一端获客，用更重的一端变现。
创始人去哪了，老用户会怎样
Turso 创始人 Glauber Costa 加入 Supabase，担任智能体服务方向负责人；联合创始人 Pekka Enberg 和团队一起并入。Turso 继续独立运营，SQLite 那条线继续做，并明确保留「应用长大之后无缝迁到 Postgres」的路径。
对现有用户，Supabase 的公开表态只有一句：什么都不会变。 但要把这句话读准——真正被承诺的是「今天不变」；Turso 的产品路线从此由 Supabase 决定，这是并购之后谁都躲不开的现实。
顺带一提并购落地时的社区反应：相关讨论帖热度不低，情绪是「松一口气」和「客户焦虑」混在一起——有人一直因为「未来押在一家创业公司身上」而不敢用，也有付费用户说这是他们最不想要的结果。
那几个数字该怎么读
这次公告里数字很漂亮，但每一个都要看清分母：
- 每周超过一百万个数据库、每月新增约四百万个数据库、每周新增用户过百万：前两个是创建量，不是付费量，也不是留存。建库数不等于收入。
- 约七成新数据库由智能体或 AI 工具创建：这个比例六月还是六成。但如果它和上面的月建库数算的是同一批样本，那么智能体每月建的库大约两百八十万个。问题是公司没说这两个数字怎么统计，也没说统计口径中途有没有变过。
- 开发者从六月的近一千万涨到现在的超一千三百万：四个月涨三百万。这个速度很猛，但同样来自公司自报。
- 一个更值得琢磨的细节：六月披露过，某个编程助手是平台上单一最大的新增数据库来源。换句话说，相当一部分增长系在一个外部产品上——这对一家正在讲「智能体基础设施」故事的公司，是机会也是风险。
补一组行业背景：同一个月里，还有几家数据库公司分别拿出面向智能体的方案，方向高度一致。「数据库加智能体基础设施」正在变成下半年最拥挤的一条赛道，Supabase 这一手是入场，不是独角戏。
对独立开发者的四条影响
抛开宏大叙事，落到你自己身上，大概有四条：
- 后端选型多了一个中间档。 以前是「SQLite 够用到某天突然不够」和「一上来就上 Postgres」二选一；现在中间多出一档「先给孩子配一个轻量库，长大了再迁」。对做副业、做小工具的人，这一档很实用。
- 迁移路径还没写出来。 官方说的是「有清晰路径」，但没有公布迁移工具，也没有兼容性保证。把「先轻后重」当成既定事实去规划，是有风险的。
- 自建部署基本不受影响。 如果你是自己跑开源版，这次收购不会动你的配置。可以记一条好消息：Turso 的引擎是 MIT 许可的开源项目，Supabase 收购后如果延续它一贯的开源习惯，这个引擎你仍然可以自己跑。
- 权限配置会变成新的日常。 给每个智能体配一个单独的库，隔离性确实更好（一个跑飞的智能体污染不了别人的数据），但要配的访问权限也成倍增加。这条不是理论风险：有安全厂商在九月底扫过一批关联数据库，发现一万六千多个实例存在可读表暴露。库越多，越容易漏。
四种场景，四种选择
如果你正在纠结，可以按场景对号入座：
- 就是给自己的小工具/副业项目配后端：直接用 Supabase 的托管 Postgres。不用折腾两个引擎，账号、存储、鉴权都是现成的。
- 智能体需要一个用完就扔的临时状态库：这才是 Turso 形状的用武之地，按需创建、闲置挂起，比给每个任务开一台 Postgres 划算得多。
- 每个客户或每个生成出来的应用要一份独立数据：「一库一租户」的隔离很干净，但要提前想好生命周期——什么时候归档、什么时候删。
- 数据必须在自己的机器上：优先选开源引擎自建，云上那套省事的部分大概率不会下放到自建版。
现在就能上手的三种方式
不用等产品线融合完，今天就能动手的三件事：
- 拿 Turso 跑一个一次性任务库。 把智能体任务里的中间状态从「往共享库里加行」改成「开一个自己的库」，再用完挂起，直观感受一下成本差别。
- 把内置的 MCP 服务接进你的编码助手。 Turso 的命令行工具自带 MCP 服务，接上之后助手能直接问「这张表什么结构」，这件事在站内写过的 MCP 协议迁移之后会更好落地。
- 先数一遍你现在有几个库、几个能公网读到。 上面那条暴露数据不是吓唬人，先把权限收一遍，再谈扩张。
如果想再往前一步，站内聊过的 Agent 插件与扩展体系和 Claude Code 的定制方式可以对照着看：一个是「Agent 能装什么」，一个是「Agent 记得什么」，这次是「Agent 的数据往哪放」——三件事凑齐，才是一个能长期跑的智能体。
两条要留神的地方
第一，别把「建库量」当成需求验证。 一个智能体为原型建的库，如果任务结束就废弃，它是服务成本，不是客户。Neon 那边披露过的数据也能佐证：AI 创建的新实例比例从三成涨到八成，但明显偏向短命的实验。判断一条基础设施赛道，要看的是有多少库最后变成真正的生产应用。
第二，「数据不外流」这句要打问号。 一次并购不改变今天的部署，但会改变明天的路线图。云优先的能力，历史上很少下放到自建版本；如果你想的是长期自主，就要现在确认你依赖的那部分是不是开源的。
老达点评
第一，这笔收购的真正赌注不在数据库技术，而在基础设施的计量单位变了。过去是「一个项目一个库」，现在是「一个智能体一个库」，甚至「一个任务一个库」。单位一变，成本结构、权限模型、运维方式全都要跟着重写。谁能把最便宜的那一端做成随手可用，谁就先接住这批新流量。
第二，便宜的一端用来获客，贵的一端用来赚钱，这个模式本身很聪明，但它有个前提：迁移真的顺。而迁移这件事恰恰是公告里最模糊的部分。在迁移工具和兼容性保证出来之前，「先 SQLite 后 Postgres」应该当方向看，别当承诺用。
第三，对个人开发者和小团队来说，今天最实在的变化不是多了个数据库，而是少了一次「要不要一上来就上重型数据库」的纠结。这是那种不性感但会天天用到的改进。
第四，库变多，暴露面就变大。 智能体一次能开几百个库，权限配错的概率也就跟着涨。上面那一万六千个能公网读到的实例，是最好的提醒：自动化把创建的成本降到接近于零，也把犯错的速度提到了同一个量级。
上手第一步
今天就花十分钟做一件小事：把你手上的智能体任务里，那些「往共享库塞中间状态」的地方列出来，挑一个改成独立的小库。感受一下建库、写、挂起的实际延迟和成本，比看十篇分析都管用。
想顺着这条线往下看，可以从 AI 智能体与自动化专题 和 老达AI实践专题 翻起。
