“我们把同一个应用构建了两次”：Harper 挑战 Vercel，性能最高相差 14 倍

数据库平台 Harper 主张采用一种将应用代码和数据放在一起的单一运行时架构。该平台与基于 Vercel 的技术栈进行的基准测试显示，在实时个性化数据工作负载方面，其性能显著更好。Harper 最近发布了 5.2 版本，引入新的记录缓存，并提高了单节点吞吐量。

这种方法与 InfoQ 在 2 月报道的一项趋势背道而驰。当时，Databricks 推出了 Lakebase，这是一款基于计算与存储分离架构构建的 PostgreSQL 数据库。Lakebase 押注于解耦各层，而 Harper 则押注于合并这些层，以获得运维简单性和成本优势。在该公司与基于 Vercel 的技术栈进行的基准测试中，进程内数据访问耗时约为 0.4 毫秒，而通过网络访问独立层的耗时约为 3 毫秒。随着页面获取更多个性化数据，这一差距还会扩大。

大多数应用技术栈会将数据路径分散到数据库、缓存和任务运行器中，每个组件都会增加一次网络跳转和一个需要运维的系统。Harper 则主张将这些组件合并到一个运行时中，让代码与数据相邻。该基准测试使用同一个共享 DataSource 契约，分别构建了两个表情符号产品目录。其中一个版本运行在 Harper 上，数据、计算和消息传递共同位于一个系统中。另一个版本运行在 Vercel 技术栈上，组合使用了 Vercel Functions、Neon Postgres、Upstash Redis 和 Ably 来实现实时功能。该团队写道：

我们将同一个应用构建了两次。一次构建在 Harper 内部，另一次构建在使用 Neon、Upstash 和 Ably 的 Vercel 上。两者拥有相同的 UI、相同的代码契约和相同的数据。唯一的变量是架构。

Harper 在美国两个区域的八种场景中进行了三轮测试，共运行了 474 次负载测试。在持续的高扇出负载下，Vercel 的无服务器自动扩缩性能优于 Harper 的单个免费节点；随着并发量增加，后者会达到吞吐量上限。结果取决于工作负载：实时数据更适合采用组件共置的运行时，而大量使用缓存的边缘交付和高并发扇出则更适合无服务器技术栈。

读取扇出：按页面大小划分的服务器端组装时间

该基准测试使用已经预热的内存数据集；当工作集超出可用内存容量时，其优势可能会缩小。该团队解释道：

Harper 和 Vercel 各自在它们为之构建的那一半 Web 场景中胜出，而这套测试方法清晰地划出了二者的分界线。Harper 的组件共置进程内架构在所有实时个性化数据路径上胜出，包括单次读取、注入实时值、服务器端流式传输、写入到读取的新鲜度，以及常规负载下的读取扇出，性能通常高出数倍，最高约为 14 倍，而且在美国东西海岸的表现一致。Vercel 则在可缓存内容方面胜出（它的 CDN 非常出色），在纯广播实时场景中也更具优势。

Harper 的 GTM 高级经理 Aleks Haugom 在《Web 个性化的五种架构》一文中讨论了不同的 Web 个性化架构，并比较了它们在延迟、数据新鲜度、可扩展性、成本和复杂性方面的权衡：

个性化读取并不是向另一个服务发送网络请求，而是对内存表进行函数调用。缓存也在进程内完成。随后，整个单元会被复制到每个区域的节点上，所有副本在全球范围内保持同步，因此每位用户都可以通过最近的节点在进程内获得服务，同时仍然看到相同的数据。

由于网络跳转会增加延迟，每次个性化读取都需要在无服务器函数与远程数据库之间进行一次往返，这项成本在高负载下可能变得十分显著。

Harper 最近发布了 5.2 版本。该版本增加了记录缓存，据该公司称，可以将重复读取速度提高至原来的 5 到 8 倍；同时，它还为每个数据库提供独立的提交路径，使大量写入不再阻塞同一进程中的无关工作。该版本解决了早期版本中的一个问题：数据库提交共享 Node.js 的 libuv 工作线程池，导致大量写入挤占同一进程中无关工作的资源。隔离提交操作后，一项无关文件系统调用的 p99 延迟从 223.7 毫秒降至 2.6 毫秒。

Harper 的基准测试早于 5.2 版本，并且尚未重新运行。

原文链接：https://www.infoq.com/news/2026/08/harper-vercel-benchmark/