SpacetimeDB 2.0 发布：独特推广方式背后，技术亮点与权衡几何？

1. SpacetimeDB 2.0 发布引关注，推广方式独特却遭质疑？

数据库市场竞争激烈，新进入者推出产品并获长期市场吸引力并非易事。2026 年 2 月 26 日，SpacetimeDB 发布数据库 2.0 版本，采用独特推广方式：发布略带超现实风格视频嘲笑竞争对手，公布看似好得难以置信却不真实的基准测试结果，同样嘲讽其他数据库。这种做法令人反感，但产品中也有有趣想法，接下来进行简短技术评测。

2. 基准测试：“最佳性能”就能获胜？SpacetimeDB 测试是否诚实？

数据库新进入者常认为“最佳性能”能获胜，实际并非如此。少数成功打造可持续数据库产品的公司靠扎实、可靠技术实力。基准测试虽有助于展示产品实力，但测试本身必须是扎实、可靠的技术成果。

SpacetimeDB 提供的基准测试存在技术缺陷，在另一组测试中与竞争对手相比表现糟糕。其根本问题在于不诚实，产品与竞争对手处于不同细分领域，却选择与做出不同权衡的数据库比较，这种比较不公平。

例如，几年前在 PlanetScale 工作时，为 MySQL 开发向量相似度搜索扩展，与 `pgvector` 产品不同，有不同权衡。若在基准测试中展示“比 `pgvector` 快 10000 倍”结果虽有吸引力，但不诚实，最终未发布该结果，而是发布客观分析文章获好评。

在该领域获胜需扎实技术工作和清晰技术文档解释产品权衡和局限性。如 Turbopuffer 基准测试结果不突出，文档中讨论“不能做什么”篇幅多，但适合其使用场景的搜索产品是市场上最好的，默默赢得客户。

SpacetimeDB 是一体化数据库 + 应用服务器，应用程序代码可在数据库内部运行，这想法有趣，像关系型数据库中的存储过程且开发者体验更好，可打造有竞争力产品。然而，与多区域、高可用的分布式数据库进行基准测试并无太大关联，在衡量每秒查询率的基准测试中虽领先，但这样的测试不诚实，展示内存中访问数据速度并解释权衡会更有吸引力，其网站却无明确技术分析。

3. 存储：写入性能出色背后，内存存储与锁机制有何影响？

SpacetimeDB 在合成基准测试中写入性能出色，因应用程序逻辑与数据库本地运行，写入数据存储高效，还通过批量写入等技巧提高效率。但要达到展示的性能指标，需做出妥协，数据存储基于内存，与传统关系型数据库管理系统不同。

对内存存储的写入操作可线性化，该系统类似前面加了锁的哈希表，证明可线性化简单。在 SpacetimeDB 实例中，整个数据库提交状态封装在读写互斥锁中，写入操作顺序执行，可线性化，但读取和写入操作不能同时进行。

若写入操作过多，读取操作会被阻塞吗？基于单个全局读写锁构建数据存储是可行技术选择，但宣传为“数据库”值得商榷，需有明确、可定制语义对读取和写入操作优先级排序，确保服务器在任何工作负载下保持响应能力。而具体行为未明确定义或解释，该互斥锁具有最终公平性，读取操作最终能获取锁，但可能随机延迟最长 0.5 毫秒。

写入操作时，全局锁被持有时用 Wasmtime 运行时执行“reducers”，期间其他 reducer 不能执行，不能向数据库写入或读取数据，reducers 不能执行 HTTP 请求。不过可使用“Procedures”，目前处于测试阶段，允许运行开销大的代码包括 HTTP 请求，内部开启事务会获取全局互斥锁，需尽快提交事务，否则系统会停滞。

读取操作通过“Views”进行，相当于只读的 reducers，获取全局互斥锁读锁，多个视图可并发运行，但视图执行期间数据库不能写入操作，视图也是编译为 WebAssembly 的任意用户代码。

4. 持久性：单互斥锁设计下，数据库一致性如何保障？

单互斥锁设计的数据库在事务关键路径上要减少操作，如不能进行 HTTP 请求和将事务持久化到磁盘。该完全基于内存的数据库有预写日志作为后盾，但 WAL 异步，定期（默认每 50 毫秒）刷新到磁盘。

能否让系统完全保持一致很复杂，因 WAL 不能同步写入，否则会阻塞其他操作。不过系统在读取时提供 `withConfirmedReads` 标志选项，允许读取操作只返回已同步到磁盘的数据，需等待最长 50 毫秒，这种行为不太符合用户习惯，假设该数据库用于“大部分临时”数据，一般查询不需要高度一致的保证。

这与 2011 年的 MongoDB 情况相似，Mongo 当时基准测试结果出色但实际表现糟糕，遭网络批评后实现合适存储引擎，如今成为成熟且有竞争力的数据库公司，但早期糟糕技术声誉仍影响部分技术人员。这表明推出数据库产品走捷径可行，但获市场认可后需偿还技术债务和声誉债务，SpacetimeDB 带有夸张营销视频会让事情更复杂。

5. 权衡：SpacetimeDB 定位“更强大的 Redis”，为何以“性能更高的关系型数据库”为标准测试？

SpacetimeDB 在特定基准测试中表现出色的技术选择未在文档中预先说明，其带来的权衡也未明确列出。它不是分布式系统，在可扩展性和可用性方面有很大限制，虽可部署“集群”，但系统性能受主实例机器的 CPU 和内存容量限制。需要足够 CPU 让数据库执行查询和应用程序执行应用逻辑，足够内存存储数据库所有数据，因完全不依赖磁盘存储，数据集超内存容量数据库会崩溃，唯一扩展方式是纵向扩展。

这些权衡合理，将 SpacetimeDB 定位为“更强大的 Redis”，而非“性能更高的关系型数据库”。令人费解的是，开发者为何以后者为标准进行基准测试。

6. 使用场景：从 MMORPG 后端到面向 LLMs，SpacetimeDB 能否转型成功？

SpacetimeDB 最初版本作为 MMORPG 的后端开发，其技术选择适合该场景，如异步刷新 WAL 记录，50 毫秒延迟可接受，游戏实例崩溃玩家也能慢慢接受。

但现在游戏工作室开发 MMORPG 少，开发多人游戏的工作室倾向用自己的内部后端。所以 SpacetimeDB v2 转向更具广泛吸引力的方向，营销页面声称“大语言模型与 SpacetimeDB 结合能发挥更大作用”，这是合理选择。然而，对于这个使用场景，它做出了可能是最糟糕的技术选择。

SpacetimeDB 核心问题在于应用程序和数据库性能及可用性由短片段用户代码决定，这些代码不能有副作用或导致阻塞，类型系统无法保证，取决于即时编译器生成的 WASM 字节码，关键部分中错误或高负载下阻塞操作可能在生产环境才发现，会降低应用程序性能和导致可用性问题，绝对不是适合 LLMs 编程的理想环境。

不过，也许开发者会将经验应用到 SpacetimeDB v3 中，推出更具弹性、适合 LLMs 的数据库，如应用程序代码可隔离、事务可按需运行、系统可自动限流等，这样的产品才值得关注。那么，SpacetimeDB 能否实现转型，推出令人期待的新版本呢？