每隔几年，「把业务逻辑下沉到数据库」的念头就会回潮一次。这周，一篇题为《SpacetimeDB: A Short Technical Review》的评测文章在 Hacker News 上传开，作者对这家主打「数据库即服务器」的初创产品做了一轮技术审视，也把一个老问题重新摆上桌面：我们到底需不需要一个独立的后端进程？
SpacetimeDB 想删掉的是什么
传统实时应用的架构是三层：客户端、应用服务器、数据库。服务器负责鉴权、业务规则和状态广播，是整个系统里最难写、最难运维的一层。SpacetimeDB（由 Clockwork Labs 开发，以开源形式发布）的方案是把这一层直接吞掉：
开发者用 Rust 或 C# 编写「模块」，编译成 WebAssembly 后上传到数据库。数据以表的形式定义在模块里，业务逻辑则写成一个个称为 reducer 的事务性函数，由客户端直接调用，在数据库内部原子执行。客户端通过 SDK 按查询条件订阅相关表，数据一变，更新就被推送到所有订阅者——没有中间的 REST 接口，没有手写的 WebSocket 广播循环。
换句话说，数据库同时承担了存储、计算和实时同步三件事。官方最看好的场景是多人游戏：游戏的 tick 循环天然就是「读状态、改状态、广播」，与这套模型几乎严丝合缝。Clockwork Labs 自己在做的 MMO《BitCraft》就是跑在这套底座上的最大示范。
一个 recycled 的想法，为何现在又行得通
这并不是全新思路。上世纪八九十年代的「智能数据库」浪潮、之后 Postgres 的存储过程，本质上都是同一个方向，但当时败给了代码可移植性、调试体验和水平扩展的难题。如今 Wasm 提供了安全沙箱和语言中立性，客户端订阅模型经由 Firebase、Supabase、Cloudflare Durable Objects 等产品反复验证，「胖数据库」的可行性比三十年前高了不少。
从评测与随后的讨论看，吸引人的地方主要集中在两点：一是砍掉整个中间层后，原型开发速度极快，一两个人的团队也能做出实时多人应用；二是事务边界清晰，reducer 天然串行执行，省去了大量并发正确性上的心智负担。
但保留意见同样具体：工程成熟度仍是最大问号，API 变动频繁、工具链和可观测性还在补课；调试一段跑在数据库里的代码，体验远不如本地起一个服务；鉴权与权限模型要靠表和 reducer 自己搭，灵活性不如成熟的中间件生态；而当所有逻辑集中于一处时，扩容、热更新和故障域的划分也都变成新问题。评论区的共识大致是：做游戏原型和小型实时应用值得一试，拿它扛关键业务还需要勇气。
简短点评
SpacetimeDB 的真正价值，未必在于「消灭后端」这个口号本身，而在于它逼我们重新审视一条被默认了二十年的架构边界——逻辑应该住在哪一层。范式转移很少因为「想法正确」而获胜，而是因为某一类新场景（这里是小型团队的实时多人游戏）从中获得了不对称的好处。等到工具链成熟、有人真用它扛住了生产流量，「数据库里长出一个服务器」才会从实验变成选项。在此之前，它至少是个值得把玩的思想实验。
参考链接：评测原文 / Hacker News 讨论