SpacetimeDB：简短的技术回顾

SpacetimeDB：简短的技术回顾 2026-02-26 数据库市场是严酷的，特别是对于新手来说。推出新产品并使自己与现有产品区分开来是非常困难的。获得长期吸引力就更难了。本周早些时候，SpacetimeDB 推出了其数据库的 2.0 版本，采用了一种独特的方法——据我所知——以前从未做过：一个有点超现实（meme-y）的视频，他们在其中嘲笑他们的竞争对手（喝“竞争对手的眼泪”）和一组看起来好得令人难以置信的基准（它们确实不是真的），并且还嘲笑其他数据库。看看该基准的大输家旁边的可爱放大镜。你必须放大才能看到它们有多糟糕！好东西。我会坦白承认我觉得这令人厌恶。但尽管如此，我认为这个产品中有一些有趣的想法，我想做一个简短的技术审查，同时尽可能公平。基准 # 数据库领域的新手常犯的一个错误是相信拥有“最佳性能”就能获胜。我在实践中从未见过这种情况。建立了可持续数据库产品的（极少数）公司通过提供良好、诚实的独立技术工作而获胜。当然，拥有基准肯定会有所帮助。但基准必须是良好、诚实的技术工作。 SpacetimeDB 提供的都不是这些。他们的测量结果存在不少技术缺陷。您可以在这里看到另一组基准测试，其中 SpacetimeDB 在竞争中表现非常差。尽管如此，这些基准的最大根本缺陷是它们不诚实。我明白他们的想法，我明白：他们不诚实，因为他们的数据库产品与竞争对手非常不同，这使得编写这样的基准测试非常有吸引力。他们的产品位于数据库空间的不同部分，他们选择将他们的产品与进行不同权衡的数据库进行比较。这是一个很有吸引力的比较，但并不公平。我会给你一个我自己经历过的例子：几年前，我在 PlanetScale 工作，我们发布了一个用于向量相似性搜索的 MySQL 扩展。我们有一些非常具体的实施目标；它与其他任何东西都非常不同，因为它是完全事务性的，矢量数据存储在磁盘上，由 MySQL 的缓冲池管理。这与 pgvector 等更简单的方法形成对比，后者使用 HNSW 并要求相似性图适合内存。这是一个非常不同的产品，具有非常不同的权衡。采用具有 32GB RAM 的 EC2 实例并将 64GB 的矢量数据放入我们的数据库中是非常有吸引力的。然后对 Postgres 实例和 pgvector 执行相同的操作。这是完全相同的机器，完全相同的数据集！它正在执行相同的查询！但 PlanetScale 每秒执行数万次操作，而 pgvector 需要超过 3 秒才能完成单个查询，因为 HNSW 图不断从磁盘来回分页。在基准测试中展示这一点确实非常有吸引力。 “我们比 pgvector 快 10000 倍！”。但现在来吧。这不诚实。是的，这是同一台机器、相同的数据集和相同的查询，但它不是同一件事。我们没有发布这些基准；相反，我们发布了实施的技术细目，没有进行不公平的比较，这受到了热烈的欢迎。您不需要“疯狂的基准”来赢得胜利。您只需要扎实的技术工作和扎实的技术写作来解释您的产品的权衡和局限性。您可以查看 Turbopuffer 的另一个示例。他们的基准并不令人印象深刻，特别是与竞争对手相比。他们的文档更多地讨论了数据库不能做的事情，而不是它可以做的事情。但每个人都知道，如果您的用例适合他们的产品，他们就会拥有市场上最好的搜索产品。领先竞争对手数英里。他们不喝竞争对手的眼泪，只是默默地抢夺客户。无论如何：回到 SpacetimeDB 及其基准。他们提供的产品与竞争对手截然不同！它是一个一体化的数据库+应用程序服务器，您可以在其中部署数据库实例，并且应用程序的代码在数据库本身内部运行。我认为这是一个非常有趣的想法。你可以说它就像关系数据库中的存储过程，但具有更好的开发人员体验。公平的。但你完全可以用它来构建一个可行的产品！然而，你必须承认，它与它自己进行基准测试的多区域、高可用分布式数据库关系不大。如果您的应用程序代码在数据库内运行，并且您的竞争对手有一个单独的应用程序，该应用程序必须为每个 q 执行单独的网络请求