The database platform Harper advocates for a single-runtime architecture that keeps application code and data together, with its benchmark against a Vercel-based stack reporting significantly better performance on live, personalized-data workloads. Harper recently released version 5.2, with a new record cache and more throughput per node.
The approach runs counter to a trend InfoQ covered in February, when Databricks introduced Lakebase, a PostgreSQL database built on the separation of compute from storage. Where Lakebase bets on decoupling layers, Harper bets on collapsing them for operational simplicity and cost advantages. Its own benchmark against a Vercel-based stack measured in-process data access at roughly 0.4ms versus a ~3ms network hop to a separate tier, a gap that widens as a page pulls in more personalized data.
While most application stacks spread the data path across a database, a cache, and a job runner, each adding a network hop and a system to operate, Harper argues for collapsing those into a single runtime that keeps code next to its data. The benchmark runs an emoji product catalog built twice behind a single shared DataSource contract. One version runs on Harper, with data, compute, and messaging co-located in one system. The other runs on a Vercel stack that wires together Vercel Functions, Neon Postgres, Upstash Redis, and Ably for real-time. The team writes:
We built one identical app twice. Once inside Harper, once on Vercel with Neon, Upstash, and Ably. Same UI, same code contract, same data. The only variable was the architecture.
Across eight scenarios and two regions in the US, Harper ran 474 load tests over three trials. Under a high, sustained fan-out load, Vercel's serverless autoscaling outperforms Harper's single free node, which hits a throughput ceiling as concurrency increases. The outcome is workload-dependent, with live data favoring the co-located runtime, while cache-heavy edge delivery and high concurrency fan-out favor the serverless stack.
Read fan-out: server-side assembly time by page size. Source: Harper benchmark.
The benchmark uses a warm, in-memory dataset; the advantage may narrow when the working set exceeds available memory. The team explains:
Harper and Vercel each win the half of the web they were built for, and this methodology makes the line sharp. Harper's co-located, in-process architecture wins every live, personalized-data path — single reads, injected live values, server-side streaming, write-to-read freshness, and read fan-out at normal load — often several-fold, up to ~14×, and symmetrically across coasts. Vercel wins cacheable content (its CDN is superb) and broadcast-only realtime.
In the article "5 Architectures for Web Personalization," Aleks Haugom, Senior Manager of GTM at Harper, discusses different architectures for web personalization, comparing their trade-offs in latency, data freshness, scalability, cost, and complexity:
A personalized read is not a network request to another service; it is a function call against an in-memory table. Caching is in-process. The whole unit is then replicated to a node in every region and the copies are kept globally in sync, so each user is served in-process by the nearest node and still sees the same data.
As the network hop adds latency, every personalized read requires a round trip between the serverless function and the remote database, a cost that can become significant under load.
Harper has recently released version 5.2, which adds a record cache that, according to the company, serves repeated reads five to eight times faster and gives each database its own commit path, so heavy writes no longer stall unrelated work in the same process. The release addresses an issue in earlier versions, with database commits sharing Node’s libuv worker pool, so heavy writes were starving unrelated work inside the same process. Isolating commits dropped the p99 of an unrelated filesystem call from 223.7ms to 2.6ms.
Harper’s benchmark predates version 5.2 and has not been re-run.