SpacetimeDB 2.0： benchmarks 太美，真相太痛
SpacetimeDB: A Short Technical Review
SpacetimeDB 发布了 2.0 版本，用一段戏谑视频和看似完美的 benchmarks 嘲讽竞争对手，但数据背后却藏着技术陷阱。作者指出，其 benchmarks 并不诚实，因为 SpacetimeDB 将应用代码直接运行在数据库内部，与传统的分布式数据库架构完全不同。这种设计虽然能带来极高的内存读写性能，但存储引擎本质上是一个带全局锁的哈希表，读写互斥，且数据仅异步写入磁盘，缺乏传统 RDBMS 的持久化保障。作者认为，与其用不公平的 benchmarks 博眼球，不如像 Turbopuffer 那样坦诚说明产品边界。SpacetimeDB 的创新值得肯定，但营销方式令人不适，技术细节也需更透明的解读。
你不需要“疯狂 benchmarks”来获胜，你只需要扎实的技术工作和清晰说明产品权衡与局限的技术文档。
HN 评论区
50- cloutiertyler
我记得有个朋友在 SpacetimeDB 还试图走 MMORPG 路线时给我看过一些东西，考虑到当时那项目里充斥着大量不必要的过度工程，我挺惊讶这家公司居然还能活到现在。
把 ECS 风格的逻辑写成代码，再把所有代码做成存储过程，这套模式确实解决了一些数据库事务问题。但二十年前 MMORPG 风靡一时、电脑速度只有现在百分之一甚至千分之一的时候，主流 MMORPG 根本没遇到过这些问题。如今投入大量工程精力去解决和消除这些数据库往返调用，而这些问题二十年前都不算事儿，现在更不算什么了。
另一方面，开发多人游戏真正的难点，比如回滚、物理引擎、碰撞检测等等，这套东西其实一点忙都帮不上。甚至可以说，它让这些问题变得更难处理了。我猜这款游戏的开发者为了能让物理引擎勉强跑起来，肯定得搞出一些相当有趣的“黑科技”，而且这些方案大概率也没从他们的数据库里得到什么好处。
再加上在数据库里使用存储过程的那些已知反模式，SpacetimeDB 完全没解决这些问题。你没法只在客户端跑测试，因为应用逻辑被拆散在客户端和数据库服务器之间，导致代码变成意大利面，游戏设计的迭代周期也变得极差。而且数据库本身也无法水平扩展，更……
- nemothekid
SpacetimeDB 的发布视频出现在我的 YouTube 推荐流里——我挺惊讶视频里完全没讲它是如何实现的。我原本以为这是某种专有黑科技，结果发现居然是开源的，这让我更困惑了。要实现他们所说的那种语义，我本以为技术相当新颖，如果是开源项目，他们应该把这点作为主打卖点才对。
有点失望地发现，这本质上就是 2015 年版的 React Flux，用 Rust 围绕一个互斥锁（mutex）实现的。
- Escapado
大体上读得很愉快，不过有个小细节想吐槽一下：
>“类型系统无法强制保证没有副作用或阻塞……”
“副作用”这部分可能没错，但“阻塞”意味着 WASM 代码调用了长时间阻塞的函数——这通常很容易用类型系统来约束，WASM 生态也常用类似 Promise 的构造来处理。所以，SpacetimeDB 这边确实需要给“这个函数可能会发起 HTTP 请求”打上标记，但这种针对可被 WASM 调用的代码的标记，本身就是一个非常正常的预期。
如果他们没提供这类标记，却在 Beta 版 API 中允许阻塞调用，那么是的，这种内部结构（共享全局锁）确实是个大问题，我完全同意。