SpacetimeDB：把服务器逻辑塞进数据库的实时后端

「Koala 聊开源」当时介绍 SpacetimeDB 的亮点是「数据库和服务器合二为一」：客户端直接连数据库，业务逻辑在数据库内部执行，用 Rust 或 C# 写 Spacetime module、编译成 WebAssembly 内置进数据库调用，从而省掉云上那套多服务架构，让小团队也能做出带实时位置与持久化状态的多人游戏。几年过去，项目更名为 Spacetime（当前 v2.10），叙事再次转向——现在它把自己定位成「AI Agent 喜爱的反应式后端平台」。本文基于其官网，拆解这个「反传统」的架构，并客观评估它的性能说法。

一、背景：传统实时后端为什么碎

做一个多人实时应用（游戏、协作工具、聊天），传统栈要拼一长串组件：Web 服务器、ORM、缓存、网络层、同步层、数据库，再加上鉴权与部署。Spacetime 官网把这条链路列了十几步（开户计费、选云服务、申请机器、配持久层、管状态……），并指出最后还逃不开原子性、一致性、隔离性问题。它的主张是：这些层全都不要，让后端逻辑直接跑进数据库里。

二、是什么：数据库即后端

官方定义：一个「反应式后端平台」，把数据库、服务器逻辑、鉴权、部署与实时同步放在一处。核心信条是「No web server, ORM, cache, networking, or sync layer to stand up. Spacetime is all of it」——开发者只面对一个系统，而不是十好几个要接线的服务。

它的几个根本设定：

• 整个应用状态就是一堆表：默认持久化，且保留每一行的完整历史；
• 订阅即同步：客户端订阅的数据变更后，Spacetime 自动把更新推给所有客户端，保持实时一致；
• Reducer 即事务：所有写操作通过 reducer 执行，每个 reducer 要么完整提交、要么根本不运行（原子）；
• 真代码跑在库里：服务器逻辑以 Rust、C# 或 TypeScript 编写，作为模块运行在数据库进程内。

三、技术机制：存储过程的「下一级」

Spacetime 自称是「通用关系型数据库，具备强可串行化 ACID 事务，并把存储过程带到了下一级」。其机制可理解为：

1. 把存储过程当后端：传统存储过程只能被服务器调用，而 Spacetime 把整个服务端业务逻辑都放进数据库模块，客户端通过 reducer 调用直接驱动；
2. WASM 模块：业务模块编译为 WebAssembly 在库内执行，获得类型安全与灵活性；
3. 反应式订阅：表的变更会自动广播给订阅客户端，省掉自研同步协议；
4. 全历史保留：默认记录每行完整历史，天然支持时间旅行与审计。

这套设计最初是为多人游戏量身定制——玩家实时位置、对局状态、持久化存档本来就是高频小事务 + 全网状广播，正好是「状态在表里 + 变更自动推」的甜蜜点。

四、关键事实与口径

五、评测方法与口径批判

这一节必须泼冷水。Spacetime 官网的性能表述是典型的营销话术，缺少可复现的测试条件：

• 「100x–1000x 更好性能」是相对「把逻辑散在多层服务里」的对比，但官方没有公布基准硬件、负载模型、对比对象（Postgres？MySQL？）与测试代码。把逻辑搬进数据库确实省掉了网络往返与序列化开销，量级上有道理，但 100x–1000x 这个数字无法独立复核；
• 「Millions of Transactions. Zero Bottlenecks」「leaves conventional databases behind」是口号，不是 SLA；
• 它把「服务器逻辑内嵌数据库」当卖点，这同时意味着它是一个有主见的 opinionated 系统：你必须接受它的 reducer 模型、订阅模型与托管/部署方式，而不是自由拼装；
• 「AI Agent 一键构建」降低了样板代码，但生产级系统的鉴权细化、权限、监控、故障处理仍需自行验证。

六、适用与不适用场景

适合：

• 多人游戏、实时协作、聊天室等高频小事务 + 广播同步的应用；
• 小团队想用最少运维做出带实时同步与持久化的产品；
• 喜欢「状态在表、变更自动推」模型、愿意接受 opinionated 框架的开发者；
• 用 AI 编程工具快速搭实时原型。

不适合：

• 复杂分析型查询、报表、大表扫描为主的负载（它是 OLTP/实时，不是分析库）；
• 需要自由选择 ORM/缓存/消息队列、保留现有微服务栈的团队；
• 对「100x–1000x」这类无出处数字敏感、需要可复现基准的严肃采购。

七、客观分析：优势与局限

优势：

1. 架构极简：DB、逻辑、鉴权、同步、部署一体，运维面积极小；
2. 天生实时：订阅自动广播，省去自研同步协议；
3. 强一致：强可串行化 ACID + 原子 reducer，正确性有底线；
4. 多语言：Rust/C#/TS 模块，门槛低。

局限：

1. 性能数字不可复核：100x–1000x 缺测试条件；
2. 高度 opinionated：绑定 reducer/订阅/模块模型，迁移成本高；
3. 非分析型：不适合 OLAP 与复杂报表；
4. 产品仍在快速转向：从游戏后端到 AI Agent 后端，早期路线与生态稳定性需持续观察。

八、它意味着什么

SpacetimeDB/Spacetime 代表了一种激进主张：与其在数据库外面堆十几层胶水，不如把后端逻辑直接放进数据库。对实时多人应用和小团队，这种「一体化」带来的开发效率提升是真实的；但它用一组没有可复现基准的夸张数字来包装自己，选型时务必以自己的真实负载做 POC，而不是被「百万事务、零瓶颈」的口号带着走。

参考来源

• Spacetime 官网
• Koala 项目库条目 #1218