Supabase 在 2026 年 10 月 2 日正式宣布收购基于 SQLite 的边缘数据库平台 Turso。Turso 联合创始人 Glauber Costa 将加入 Supabase 负责领导 Agent 基础设施业务，另一位联合创始人 Pekka Enberg 及核心团队悉数并入。两家公司承诺原有服务继续运转，Supabase 坚守 Postgres，Turso 持续推进 SQLite。
表面上看，这是一桩典型的基础设施收编案，实质却是云原生数据库底层经济学被生成式智能体彻底逼入死角后的断腕重组。当自主运行的代码在数秒内就能拉起一组应用原型或临时工作流，传统基于独立虚拟机或计算容器的数据库分配逻辑瞬间崩盘，逼得一直以 Postgres 捍卫者自居的 Supabase，必须向轻量级的 SQLite 借道突围。
每周 100 万新建库的洪流，击穿了容器的账本
在人类工程师主导开发的时期，数据库的生命周期通常以月甚至年为单位，哪怕采用多租户共享方案，也是数十个业务平摊一套稳固的实例资源。但自主智能体打破了这一规律。一个 Agent 为验证一个接口、生成一张报表或隔离一段短期对话，就会随时随地申请一个崭新的数据库，用后即弃。
Supabase 自身的运行数据印证了这种井喷：平台每周启动的数据库数量已经突破 100 万个。然而，Supabase 标准架构是为严谨生产环境设计的，依赖独立的计算单元与容器实例。在现行商业定价中，Supabase Pro 方案月费 25 美元，每额外增加一个独立项目就需要加收约 10 美元/月（附带 8 GB 磁盘）。如果让 Agent 照这个频率建库，账单会在几小时内拖垮任何一个开发团队。
与此同时，云端状态层的争夺战早已打响。Cloudflare D1 依托 Workers 生态以每月 5 美元起步，但强制限制单个账户最多 50,000 个数据库，单库上限 10 GB 且采用单线程排队执行；Serverless Postgres 阵营的 Neon 针对 Agent 平台开出专项通道，按 0.106 美元/CU-小时计费，但需要企业通过审核绑定 Scale 计划。
Turso 恰恰切中了这块生态空白：其 Developer 方案每月仅售 5.99 美元，允许无限制创建数据库，并附带 9 GB 存储、25 亿行读取、2500 万行写入以及 10 GB 的同步额度；即使面向业务扩容的 Scaler 方案，起步也只需 29 美元/月。如果 Supabase 不迅速买下这套能力，海量的自动化原型开发就会被边缘 SQLite 体系拦截吞食。
借 Rust 微内核脱壳：把数据库重构成冷热挂起的文件
由 ex-ScyllaDB 核心团队操刀的 Turso 并不是单纯的云管 SQLite。它的技术栈由三层构成：早期基于 C 语言改写、带有网络同步能力的 libSQL 分叉；随后完全用 Rust 重写、支持异步 I/O 与并发写入的独立存储引擎 Turso Database；以及由 Rust 多租户微服务与 Go 控制平面搭建的托管平台 Turso Cloud。
这套体系的核心思想在于将计算与存储深度剥离。Turso 的持久化数据全部存放在 AWS S3 或 S3 Express 对象存储中，本地 NVMe 磁盘仅仅充当缓存加速层。
官方高调宣传的“单台物理服务器承载数百万数据库”，包含着极严苛的前提条件。该指标依托的是将长期没有流量的数据库挂起并推入冷存储的能力，而不是让数百万个活跃实例同时承受实时高并发冲击。
性能表现需要剥离营销话术来审视。Turso 在 2026 年 9 月 29 日刚发布的 0.8 版本基准测试显示，在 64 连接并发写入下，其吞吐能达到约 9,500 TPS，而相同硬件下的原版 SQLite 3.50.2 仅有约 1,370 TPS；在 32 连接并发下，其 p99.9 延迟降至 2.4 毫秒，原版测试则需约 1.2 秒。
但这绝不意味着 Turso 的云端综合性能达到 Neon、Supabase 或 D1 的七倍。实际上，在最基准的单连接吞吐测试中，原版轻装上阵的 SQLite 执行速度依然更快。官方早前声称的 312 倍同步加速，实际上是把 Local-first 场景下的本地批量持久化，与频繁跨公网请求远程数据库做了比较，本质属于架构路径带来的网络往返红利，不能等同于通用 SQL 处理能力的代际超越。
所谓单机百万数据库，本质是元数据索引结合冷挂起的高密度托管，绝非同时活跃的写入奇迹。
跨引擎升级的断层与无限建库的暗礁
官方在合并公告中勾勒了一副蓝图：智能体在开发验证阶段使用低成本的 SQLite，等业务规模扩大后无缝迁移至 Postgres。但这种说法回避了一个极度繁琐的工程现实——两款数据库之间目前根本不存在开箱即用的自动化升级工具。
| 评估维度 | Supabase 传统原生方案 | Turso 架构接入方案 | 开发者真实处境与工程判定 |
|---|---|---|---|
| 底层引擎机制 | 标准 Postgres 关系型内核 | Rust 重构 SQLite (libSQL) | 语法、扩展插件与类型系统截然异构 |
| 单库起步成本 | 附加项目约 $10/月 | $5.99/月无限量建库 | 解决微型项目冷启动门槛，大幅降低测试损耗 |
| 并发写入支持 | 生产级行级锁成熟支持 | 仅限特定配置下的预览功能 | 高频写入受限于 BEGIN CONCURRENT 语法 |
| 平滑进阶能力 | 纵向平滑扩容计算资源 | 缺乏一键全自动转换工具 | 业务扩张至生产环境需重新重构 Schema |
从 SQLite 跨越到 Postgres 属于异构引擎移植。二者在方言语法、数组类型、复杂 JSON 查询以及存储过程实现上存在巨大鸿沟。Turso Cloud 当前的并发写入能力依旧停留在预览阶段，仅限于特定的 tursodb 数据库配合 BEGIN CONCURRENT 语法运作。开发者一旦选择在 Turso 上完成原型构建，当需要接入 Postgres 生产生态时，代码层与 Schema 的推倒重构不可避免。
- 风险.无限建库并不等于零持有成本，闲置在 S3 的微型库超额存储费达 0.75 美元/GB，若任由智能体肆虐建库而不做清理，沉淀的冷数据将变成持续漏费的账单黑洞。
开源层面的不确定性同样在发酵。虽然 SQLite 源码处于公有领域（Public Domain），Turso 核心维护的 libSQL 项目也基于宽松的 MIT 许可证开源，被收购本身不会影响现有公开代码的分发与调用。但随着 Glauber Costa 与核心研发全员并入 Supabase 执掌战略基建，后续代码的演进重心是倾向于公共基础库，还是彻底沦为商业云服务的前置搭头，社区依然保留着戒心。
Neon 至今仍坚持全生命周期的纯血 Postgres 分支路线，试图通过按秒挂起的轻量计算来迎战。而 Supabase 选择以收购方式组装“前段 SQLite 垫底、后端 Postgres 兜底”的双轨模型。对 Mastra、CTO.new 这类已经接入 Turso 的智能体开发者而言，短期内确实保住了极低的状态隔离成本；但在全自动跨引擎迁移工具落地之前，切忌把两座异构底座的接缝，当成平整坚固的高速公路。