Harper released version 5.2 with benchmark results comparing its mono-stack architecture against Vercel's four-component stack (Vercel Functions + Neon Postgres + Upstash Redis + Ably). The published benchmark predates 5.2, but shows Harper up to 14x faster on personalized-data paths. Version 5.2 adds a per-worker record cache, isolated commit scheduling, and a new SQL query planner, tested across 474 load tests in eight scenarios in two US regions.
In the test, a product catalog was built twice on the same data contract: once on Harper (data, compute, cache, and messaging in one process), once on Vercel's components. A single in-process read costs roughly 0.4ms; a network hop to a separate tier costs roughly 3ms. Across live-data scenarios—single reads, injected live values, server-side streaming, write-to-read freshness, read fan-out at normal load—Harper reported up to 14x faster throughput.
The benchmark has limits. Under high, sustained fan-out load, Vercel's serverless autoscaling outperforms Harper's single free node. Vercel wins on cacheable static content via CDN and broadcast-only real-time. The test used a warm, in-memory dataset; the in-process advantage narrows when the working set exceeds available RAM.
Version 5.2 targets the throughput ceiling. In earlier builds, database commits shared Node's libuv worker pool with all other async work, so heavy writes starved unrelated operations. Harper isolated each database to its own commit path. During heavy writes, median latency of unrelated async work dropped from 15.1ms to 0.12ms; p99 dropped from 223.7ms to 2.6ms—an 86x reduction. Worst-case p99 on a strained 46 GB database dropped from 51ms to 3.4ms. Raw commit throughput is unchanged; the gain is isolation, not speed.
| Metric | Before (shared libuv pool) | After (isolated commit path) | Reduction |
|---|---|---|---|
| Median latency — unrelated async work | 15.1 ms | 0.12 ms | ~126× |
| p99 latency — unrelated async work | 223.7 ms | 2.6 ms | ~86× |
| Worst-case p99 — strained 46 GB database | 51 ms | 3.4 ms | ~15× |
The per-worker record cache uses lock-free atomic version slots to serve repeated reads without hitting the storage layer when the cached version is current. Warm reads ran 5–8x faster; transactional reads 5x faster; vector search 2.6x faster. Cold reads are unchanged. The new SQL query planner routes supported queries directly against Harper's indexes rather than through a generic execution layer. Retrieving ten records by primary key from a 40,000-row table dropped from 133.6ms to 1.65ms. All 16 supported query shapes in the benchmark completed faster with identical results verified before timing.
| Feature | Operation | Before | After | Speedup |
|---|---|---|---|---|
| Per-Worker Record Cache | Warm reads | — | — | 5–8× |
| Per-Worker Record Cache | Transactional reads | — | — | 5× |
| Per-Worker Record Cache | Vector search | — | — | 2.6× |
| Per-Worker Record Cache | Cold reads | — | — | Unchanged |
| SQL Query Planner | Primary-key lookup (10 records / 40K-row table) | 133.6 ms | 1.65 ms | ~81× |
Scheduling, backup, routing, request filtering, encrypted secrets, and agent orchestration can run inside the Harper runtime rather than as separate integrations. Fewer integrations mean fewer credentials, failure modes, and upgrade cycles. As Harper stated: "Reducing architectural boundaries is not an aesthetic preference. It means fewer places for latency to accumulate, fewer contracts to keep synchronized, and fewer systems to investigate when something breaks at 2 a.m."
Harper's core is Apache 2.0; Harper Pro adds multi-node replication, certificate management, and extended profiling under the Elastic License 2.0.