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 后端到面向 LLMsSpacetimeDB 能否转型成功SpacetimeDB 最初版本作为 MMORPG 的后端开发其技术选择适合该场景如异步刷新 WAL 记录50 毫秒延迟可接受游戏实例崩溃玩家也能慢慢接受。但现在游戏工作室开发 MMORPG 少开发多人游戏的工作室倾向用自己的内部后端。所以 SpacetimeDB v2 转向更具广泛吸引力的方向营销页面声称“大语言模型与 SpacetimeDB 结合能发挥更大作用”这是合理选择。然而对于这个使用场景它做出了可能是最糟糕的技术选择。SpacetimeDB 核心问题在于应用程序和数据库性能及可用性由短片段用户代码决定这些代码不能有副作用或导致阻塞类型系统无法保证取决于即时编译器生成的 WASM 字节码关键部分中错误或高负载下阻塞操作可能在生产环境才发现会降低应用程序性能和导致可用性问题绝对不是适合 LLMs 编程的理想环境。不过也许开发者会将经验应用到 SpacetimeDB v3 中推出更具弹性、适合 LLMs 的数据库如应用程序代码可隔离、事务可按需运行、系统可自动限流等这样的产品才值得关注。那么SpacetimeDB 能否实现转型推出令人期待的新版本呢 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 后端到面向 LLMsSpacetimeDB 能否转型成功SpacetimeDB 最初版本作为 MMORPG 的后端开发其技术选择适合该场景如异步刷新 WAL 记录50 毫秒延迟可接受游戏实例崩溃玩家也能慢慢接受。但现在游戏工作室开发 MMORPG 少开发多人游戏的工作室倾向用自己的内部后端。所以 SpacetimeDB v2 转向更具广泛吸引力的方向营销页面声称“大语言模型与 SpacetimeDB 结合能发挥更大作用”这是合理选择。然而对于这个使用场景它做出了可能是最糟糕的技术选择。SpacetimeDB 核心问题在于应用程序和数据库性能及可用性由短片段用户代码决定这些代码不能有副作用或导致阻塞类型系统无法保证取决于即时编译器生成的 WASM 字节码关键部分中错误或高负载下阻塞操作可能在生产环境才发现会降低应用程序性能和导致可用性问题绝对不是适合 LLMs 编程的理想环境。不过也许开发者会将经验应用到 SpacetimeDB v3 中推出更具弹性、适合 LLMs 的数据库如应用程序代码可隔离、事务可按需运行、系统可自动限流等这样的产品才值得关注。那么SpacetimeDB 能否实现转型推出令人期待的新版本呢