The database platform Harper measured in-process data access at roughly 0.4 milliseconds compared to a roughly 3-millisecond network hop to a separate tier in a benchmark against a Vercel-based stack, a performance gap that grows wider as a page incorporates more personalized data. The company published benchmark results in August 2026 that advocate for a single-runtime architecture keeping application code and data together, challenging the industry trend toward separating compute from storage. Harper recently shipped version 5.2, which includes a new record cache and increased throughput per node.

The benchmark constructed an emoji product catalog twice using a single shared DataSource contract—once inside Harper with data, compute, and messaging co-located in one system, and once on a Vercel stack combining Vercel Functions, Neon Postgres, Upstash Redis, and Ably for real-time capabilities. Across eight scenarios and two regions in the United States, Harper ran 474 load tests over three trials. Under high, sustained fan-out load, Vercel's serverless autoscaling exceeded Harper's single free node performance, which reached a throughput ceiling as concurrency climbed. The outcome proved workload-dependent, with live data favoring the co-located runtime while cache-heavy edge delivery and high concurrency fan-out favored the serverless stack. Harper's co-located architecture won 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 by several-fold margins, reaching up to roughly 14 times faster, with consistent results across both coasts.

The team writes that they "built one identical app twice," with the same user interface, the same code contract, and the same data, making architecture the only variable. According to Aleks Haugom, senior manager of GTM at Harper, a personalized read becomes a function call against an in-memory table rather than a network request to another service, with caching handled in-process. The report finds that "Harper and Vercel each win the half of the web they were built for, and this methodology makes the line sharp," with Vercel winning cacheable content delivery through its CDN and broadcast-only realtime, while Harper dominates personalized data paths.

Harper's approach runs counter to the architectural direction taken by platforms like Databricks, which introduced Lakebase in February 2026—a PostgreSQL database built on separating compute from storage. Where Lakebase bets on decoupling layers, Harper wagers on collapsing them for operational simplicity and cost advantages. Most application stacks distribute the data path across a database, a cache, and a job runner, with each component adding a network hop and a system to operate, but Harper argues for consolidating those into a single runtime that positions code next to its data. The benchmark used a warm, in-memory dataset, and the advantage may shrink when the working set surpasses available memory. Version 5.2 addresses an issue in earlier versions where database commits shared Node's libuv worker pool, causing heavy writes to starve unrelated work inside the same process—isolating commits reduced the p99 of an unrelated filesystem call from 223.7 milliseconds to 2.6 milliseconds.

The release 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. Harper's benchmark predates version 5.2 and hasn't been re-run, suggesting the performance gap documented may now be larger with the latest release. The takeaway is clear: for applications serving personalized, live data where every millisecond counts, co-locating compute and storage delivers measurable speed gains over distributed architectures, while serverless stacks maintain their edge for cacheable content and high-concurrency workloads. The architectural debate between unified and separated layers will likely intensify as platform vendors optimize for increasingly distinct use cases, forcing engineering teams to match infrastructure choices more precisely to their specific workload profiles.