Harper 5.2 Gives Each Database Its Own Commit Path, Cutting P99 Latency for Unrelated Work From 223.7ms to 2.6ms

Overview

Harper shipped version 5.2 of its single-runtime application-and-database platform on August 20, 2026, adding a record cache for repeated reads and giving each database its own commit path so that heavy writes no longer stall unrelated work in the same process, according to Harper’s release announcement and InfoQ, which dated the release to August 20.

What We Know

Commits get their own thread. In earlier Harper versions, database commits competed for a shared pool of worker threads with other asynchronous work in the process, and unrelated operations could queue behind database commits under sustained write pressure, according to Harper. In a technical write-up, Harper SVP of Engineering Kris Zyp explained that every asynchronous transaction commit previously occupied one of Node.js’s shared libuv worker threads — Node provides four such slots by default, shared with filesystem operations, crypto, DNS, and RocksDB reads that miss the block cache, according to Harper. Harper 5.2 gives each database a dedicated commit thread instead. In a heavy-write benchmark, the median latency of an unrelated fs.stat call fell from 15.1 milliseconds to 0.12 milliseconds — an improvement of roughly 125 times — and its p99 latency fell from 223.7 milliseconds to 2.6 milliseconds, according to Harper and InfoQ, which independently reported the same 223.7ms-to-2.6ms figure. Under a stress test against a strained 46-gigabyte database with compaction debt, the worst-case p99 fell from 51 milliseconds to 3.4 milliseconds, while average commit throughput improved by 11%. Raw commit throughput on the standard benchmark rose only from 804 to 844 commits per second, which Harper says shows the change is about isolation rather than raw speed.

A new record cache speeds up repeated reads. Harper 5.2 adds a cache that lets repeated reads skip the storage layer while still confirming the returned record is current. In Harper’s benchmarks, warm point reads ran five to eight times faster, transactional reads about five times faster, and vector search roughly 2.6 times faster, with index builds about 2.4 times faster, according to Harper. Cold reads are unchanged, since the first request still has to retrieve the record from storage.

A new SQL engine plans queries against indexes directly. Harper 5.2 makes a new SQL execution engine the default, planning supported queries directly against Harper’s indexes and falling back to the legacy engine for query shapes it doesn’t yet support. In one benchmark, retrieving ten records by primary key from a 40,000-row table took 133.6 milliseconds through the old query path and 1.65 milliseconds through the new engine, according to Harper. All 16 supported query shapes in the benchmark ran faster under the new engine, with results verified as identical between the two.

The release is built around a single-runtime argument. Harper positions the release inside a broader architectural pitch: that combining application code, database, cache, and messaging in one runtime beats a stack that spreads them across separate systems. According to Harper’s benchmark report: “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 474 test runs spanning two U.S. regions, Harper measured a median personalized read at 0.35 milliseconds against 2.98 milliseconds on the Vercel stack — about 8.5 times faster — and reported beating Vercel by 4 to 14 times on live, personalized-data workloads such as read fan-out at normal load, according to Harper. InfoQ independently reported the same benchmark ran across eight scenarios and three trials, and rounded the core latency gap to roughly 0.4 milliseconds versus about 3 milliseconds.

The comparison isn’t one-sided. Harper ran the benchmark on a single free-tier node — 1 vCPU and 1 gigabyte of RAM — according to Harper, and under high, sustained fan-out load, Vercel’s serverless autoscaling outperforms that node once concurrency exceeds its ceiling, according to both Harper and InfoQ. Vercel’s CDN also wins on cacheable static pages, edging out Harper by about 4 milliseconds at the median, and its Ably-based realtime delivery beats Harper’s for broadcast-only updates, according to Harper. As Harper Senior Manager of GTM Aleks Haugom put it in a separate post on personalization architecture: “A personalized read is not a network request to another service; it is a function call against an in-memory table,” according to Harper.

Harper’s single-runtime pitch runs counter to a different trend in the database market that InfoQ covered in February, when Databricks introduced Lakebase, a PostgreSQL database built on the separation of compute from storage, according to InfoQ.

What We Don’t Know

Harper has not re-run its Vercel benchmark since shipping 5.2, so the reported 4-to-14x advantage on personalized reads reflects the pre-5.2 architecture rather than the record-cache and commit-isolation improvements in the new release, according to InfoQ. The benchmark also runs against a warm, in-memory dataset, and the advantage may narrow when the working set exceeds available memory, per the same report.