一、事件回顾：Supabase 把 SQLite-in-Rust 团队整体吃下
2026 年 10 月初，Supabase 官方博客发表 Supabase is acquiring Turso 一文，确认把 Turso 团队（Glauber Costa、Pekka Enberg 等核心工程师）整体并入 Supabase 领导层。Turso 是过去两年最受关注的 SQLite 替代项目：用 Rust 重写 SQLite 内核，让单台服务器可以管理百万级数据库实例，按需加载 / 挂起，定位是"为 Agent 而生的轻量数据库"。
收购完成后，Supabase 的产品线从 Postgres + Auth + Storage + Edge Functions + Realtime 扩展到 Postgres + SQLite（via Turso），且明确表态：
- Supabase 主线仍是 Postgres，AI agent 规模上来后再迁到 Postgres；
- Turso 团队继续运营，保留 SQLite in Rust 路线；
- Glauber Costa 负责 Agentic 基础设施方向。
这不是一笔孤立的收购。把它放到过去 30 天的数据库资本版图里看：
- 9 月 11 日，PlanetScale 公布 Neki：单分片 20 万 QPS、512 分片目标 1.185 亿 QPS；
- 9 月 17 日，Neon 宣布 “The Neon backend is GA”，把 agent-ready 列为头号场景；
- 9 月 28 日，pgEdge Starfleet 发布，专门桥接 “AI 原型到生产” 鸿沟；
- 10 月初，AWS 收编 DuckLabs（DuckDB 商业实体）。
四件事连起来看，“数据库 + Agent 基础设施” 正在变成 2026 年下半年最拥挤的赛道。
二、为什么是 SQLite？为什么是 Rust 重写？
Turso 的核心技术点不在 SQLite，而在 libSQL——一个 Rust 重写的 SQLite 内核，向上保持 wire-compatible，向下做四件事：
- 异步 I/O 与协程调度：把 SQLite 的同步模型拆成可在 async runtime 上跑的 pipeline，单实例支持更多并发。
- 按页缓存 + 分片挂起：把冷数据按页（4 KiB ~ 16 KiB）切到对象存储，热页留在内存，实例挂起时只保留元数据。这是 “百万级数据库 / 单服务器” 的物理基础。
- HTTP-first 协议：绕过 ODBC / JDBC，直接走 HTTPS，对 Serverless runtime（Cloudflare Workers、Vercel Edge、Deno Deploy）友好。
- 嵌入式复制：库内 Raft-like 协议，把嵌入式单机 SQLite 升级为多副本嵌入式。
这四点叠加，让 SQLite 第一次具备了 “类 Redis 的弹性 + 类 SQLite 的零运维” 双重特征。Cloudflare D1、Neon serverless driver、Supabase edge functions，本质都在追求同一个目标：让前端代码伸手就能拿到一份数据库，不必关心连接池、TCP 握手、TLS。
三、Supabase 收购 Turso 的三条产品逻辑
第一条：填补 “Agent 时代小工作负载” 空白。 Supabase 自己说"每周启动超过一百万数据库"，但这些库大部分是 Postgres 集群里切出来的逻辑库。要做到 “每个 Agent 一份数据库，agent 死了数据库自动挂起”，Postgres 集群成本太高，SQLite 才是合适单位。Turso 的 libSQL 正好补上这块。
第二条：把 “开发体验” 从 Postgres 扩到 SQLite。 Supabase 的核心资产是 SDK + 控制台 + 鉴权 + RLS 这条链。如果 Turso 也跑同一条链，开发者写 Supabase client 时不用关心底下是 Postgres 还是 SQLite——Supabase CLI、Supabase Studio、Supabase Auth 都能复用。这是 “同一平台，多种数据库” 的体验统一。
第三条：把 SaaS 边界推到 “数据库形态路由” 层。 收购后 Supabase 不再是单一 Postgres 服务商，而是 “按 workload 路由数据库形态” 的平台：小负载走 SQLite (Turso)、中负载走 Postgres Serverless、大负载走 dedicated Postgres。这条路线 Databricks / Neon 也在走（Neon + Databricks Lakebase），Supabase 必须跟上。
四、对国产数据库的三点启示
启示一：Serverless / Agent 场景下，Postgres 不是唯一解。 国内过去两年几乎一边倒在推 “Postgres 兼容”（OpenGauss、PolarDB-PG、GaussDB），但 Agent 时代的小工作负载、edge 部署、嵌入式副本需求，SQLite / libSQL 形态更合适。OceanBase 的 OBKV、PolarDB 的 PolarDB-X 走的是 “分布式 + 大集群” 路线，对百万级小库 / 单实例挂起的覆盖较弱。可以参考的方向：把 SQLite 内核做 Rust 化、加异步 I/O、加对象存储分页，作为轻量前端。
启示二：收购一家有 “内核话语权” 的小公司，比自研更快。 Databricks 收 Neon、Supabase 收 Turso、AWS 收 DuckLabs，这三笔都是 “云厂买开源内核团队” 的标准打法。国产云里阿里 / 腾讯 / 字节如果要做 agent-ready 数据库，自研周期太长，更现实的是扶持或者直接收购一个 libSQL / SQLite 替代品团队。
启示三：Database-per-Agent 商业模式值得严肃评估。 “为每个 agent 配一份数据库” 听起来夸张，但 Supabase 已经跑通 “每周 100 万数据库”。按 agent 数量 100 倍增长估算，国内云厂商 1-2 年内会撞到这个需求点。提前布局的对象存储 + 按页缓存 + 自动挂起，是绕不开的工程问题。
五、给技术人的结论
- 如果你在做 agent 平台或 edge runtime，Turso / libSQL 是值得在原型阶段就引入的依赖，不必等到流量上来再换。
- 如果你在传统企业做 OLTP，Postgres 仍是主力；但建议把 SQLite / libSQL 列为 “边缘部署 / 嵌入式副本 / 离线缓存” 的备选形态，开始做兼容性测试。
- 如果你在云厂商规划数据库产品线，“百万级小库 + 自动挂起” 是接下来 12 个月的必答题，可以参考 Turso 的工程实现 + Supabase 的产品形态。
- 如果你只是用 Supabase / Neon 这类 Serverless Postgres，本次收购对你没有直接冲击——但意味着 Supabase 的免费层可能在 2027 年扩大覆盖到 SQLite 形态，值得跟踪。
参考资料
- Supabase 官方收购公告：https://supabase.com/blog/supabase-is-acquiring-turso
- Turso 官网：https://turso.tech/
- libSQL 仓库：https://github.com/tursodatabase/libsql
- Neon backend GA：https://neon.com/blog/neon-backend-is-ga.md
- Databricks × Neon：https://neon.com/blog/neon-and-databricks.md
