2026-02-26 数据库市场非常严酷，尤其对于新手。推出一款新产品并与现有产品区分开来是非常困难的。更难的是获得任何长期的吸引力。本周早些时候，时空数据库推出了他们数据库的2.0版，采用了一个独特的方法——据我所知，这是前所未有的：一个略显超现实（有些搞笑）的宣传视频，他们在视频中嘲笑竞争对手（喝着“竞争对手的眼泪”），以及一系列看似过于完美的基准测试（实际上它们不真实），也在嘲笑其它数据库。看看那些基准测试中的大输家的可爱放大镜。你得放大去看看它们有多烂！不错的东西。我坦诚地说，我觉得这很令人反感。但尽管如此，我认为这个产品中有一些有趣的想法，我想在尽可能公正的情况下做一个简短的技术评审。基准测试# 新手在数据库领域常犯的一个错误是相信通过“最佳性能”可以获胜。实际上我从未见过这样的情况。（极少数）那些构建可持续数据库产品的公司是通过提供好的、诚实的技术工作获得胜利的，技术本身就是它们的支撑。当然，拥有基准测试确实有帮助。但基准测试必须是好的、诚实的技术工作。时空数据库提供的基准并不符合这些标准。它们在测量方面存在相当多的技术缺陷。你可以在这里看到一个替代基准集，其中时空数据库与竞争对手相比表现非常糟糕。尽管如此，这些基准的一个重大根本缺陷是它们并不诚实。我理解它们的出发点：它们之所以不诚实，是因为它们的数据库产品与竞争对手非常不同，这使得它们格外诱人去写这样的基准。它们的产品处于数据库领域的不同细分市场，而它们选择将自己的产品与进行不同权衡的数据库进行比较。这种比较是很有吸引力的，但并不公平。我来给你举个例子，这是我亲身经历过的：几年前我在PlanetScale工作，我们为向量相似性搜索发布了一个MySQL扩展。我们对实现有一些非常具体的目标；它与市场上其他所有产品都非常不同，因为它是完全事务性的，而向量数据则存储在磁盘上，由MySQL的缓存池管理。这与使用HNSW并要求相似性图保持在内存中的更简单的方法（如pgvector）形成鲜明对比。这是一个非常不同的产品，具有非常不同的权衡。在这种情况下，用一台32GB内存的EC2实例将64GB的向量数据放入我们的数据库中是非常诱人的。然后用Postgres实例和pgvector做同样的事。这是完全相同的机器，相同的数据集！它在进行相同的查询！但PlanetScale每秒可以进行数万个查询，而pgvector却需要超过3秒才能完成一个查询，因为HNSW图不断地从磁盘上调回。这在基准测试中确实是非常诱人的。我可以说“我们比pgvector快10000倍！”但说实话，这并不诚实。是的，使用的是同一台机器、相同的数据集，以及相同的查询，但这并不是同一回事。我们没有发布这些基准测试；相反，我们发布了实现的技术细节，没有不公平的比较，得到了很好的反馈。你不需要“疯狂的基准测试”来取得成功。你只需要扎实的技术工作和扎实的技术写作，说明你的产品的权衡和局限性。你可以看到另一个例子，Turbopuffer。他们的基准测评并不令人印象深刻，尤其是与竞争对手相比。他们的文档中讨论数据库无法执行的事情的行数多于可以执行的事情。但大家都知道，如果你的用例符合他们的产品，他们在市场上提供的搜索产品是最好的，远远领先于竞争对手。他们不喝竞争对手的眼泪，他们只是安静地吸引客户。无论如何：回到时空数据库和他们的基准测试。他们的产品与竞争对手非常不同！它是一款全能型数据库+应用服务器，你只需部署一个数据库实例，你的应用代码就在数据库内部运行。我认为这是一个非常有趣的想法。你可以说它就像关系数据库中的存储过程，但开发者的体验更好。这是公平的。但你完全可以基于此构建一个可行的产品！然而，你必须承认，它与那些在多区域、高可用分布式数据库中进行基准测试的产品几乎没有关系。因为如果你的应用代码在数据库内部运行，而你的竞争对手有一个单独的应用，必须为每个查询执行单独的网络请求，那么是的，在这个方面你应该占优势。