Harper's Single-Runtime Architecture: Performance Insights

Harper, a database platform, recently released version 5.2 and made a compelling case for a single-runtime architecture that co-locates application code and data. This approach stands in contrast to the industry trend of separating compute from storage, as exemplified by Databricks' Lakebase. In Harper's recent benchmark against a Vercel-based stack, Harper demonstrated significantly better performance for live, personalized-data workloads. This improvement is largely attributed to in-process data access, which eliminates the network hop required by traditional multi-system stacks, thereby reducing latency and improving performance.

Why This Matters

For engineers maintaining production codebases, the choice of architecture can greatly affect performance, cost, and complexity. Harper's single-runtime architecture simplifies operations by collapsing data, compute, and messaging into a unified system. This can lead to cost advantages and operational simplicity, especially for applications that demand low-latency, personalized data processing.

Performance Comparison

The benchmark conducted by Harper involved building an identical emoji product catalog app twice: once using Harper's architecture and once on a Vercel stack. Both versions shared the same UI, code contract, and data, with the primary variable being the architecture. Harper's in-process data access achieved a latency of roughly 0.4 milliseconds, compared to a 3-millisecond network hop in the Vercel stack. This difference becomes more pronounced as the application requires more personalized data.

Across eight scenarios and two regions in the US, Harper ran 474 load tests over three trials. The results showed that under high, sustained fan-out load, Vercel's serverless autoscaling performed better than Harper's single free node. However, Harper's architecture was more favorable for live data scenarios, often outperforming serverless setups several-fold, up to 14 times in some cases. This is particularly evident in single reads, injected live values, server-side streaming, write-to-read freshness, and read fan-out at normal load. The methodology highlighted the sharp line between the architectures: Harper's co-located, in-process architecture excels in live, personalized-data paths, while Vercel's stack is better suited for cacheable content and broadcast-only real-time scenarios.

Limitations and Trade-offs

While Harper's single-runtime architecture shines in scenarios involving live, personalized data, it is not without limitations. The benchmark used a warm, in-memory dataset, and the performance advantage may narrow if the working set exceeds available memory. Additionally, Vercel's stack is better suited for cache-heavy edge delivery and high concurrency fan-out scenarios, where its serverless architecture and CDN excel. The choice between these architectures will depend on the specific needs of the application, such as the balance between personalized live data and cacheable content delivery.

Harper's recent 5.2 release adds a record cache for faster repeated reads and isolates database commits to prevent them from stalling unrelated processes. This addresses earlier issues where commits could interfere with unrelated tasks, as heavy writes shared Node's libuv worker pool. The new release reduces the p99 latency of unrelated filesystem calls from 223.7ms to 2.6ms, showcasing significant improvements in handling concurrent tasks. This isolation of commit paths can be critical for applications experiencing heavy write operations, ensuring that performance remains consistent and predictable under load.

What I'd Do on Monday

As an engineer working with databases and web architectures, the insights from Harper's benchmark provide a clear direction for optimizing performance in specific scenarios. Here's what I would consider doing:

• Evaluate Architecture Needs: Assess whether your application would benefit from reduced latency and operational simplicity through Harper's single-runtime architecture, especially if your workload involves live, personalized data. Consider the trade-offs of co-locating data and compute versus using a multi-system stack.
• Consider Harper 5.2: If you are facing issues with heavy write operations impacting unrelated tasks, consider upgrading to Harper 5.2 to benefit from the isolated commit paths and improved caching. This could be particularly beneficial in applications where write performance is a bottleneck.
• Benchmark Your System: Conduct similar benchmarks in your environment to measure the impact of architecture changes. This will provide concrete data to guide decision-making. Pay attention to the specific workloads and scenarios that are most relevant to your application.
• Balance Needs: For applications that rely heavily on cacheable content and high concurrency, consider maintaining a multi-system stack with serverless capabilities like Vercel, which excels in these areas. Weigh the benefits of serverless scalability and CDN performance against the simplicity and direct data access of a single-runtime architecture.

Considerations and Future Directions

Choosing between a single-runtime architecture and a multi-system stack will depend on the specific requirements of your application. If your use case involves frequent personalized reads and low-latency data access, Harper's approach may offer significant advantages. However, for applications that prioritize cacheable content delivery and require extensive scalability, a serverless stack might still be the better option. Consider the operational complexity, cost implications, and performance characteristics of each approach.

Ultimately, the decision should be based on a thorough understanding of your application's performance bottlenecks and operational needs. Future developments in database technologies and architecture paradigms will continue to influence these choices, and keeping abreast of updates from platforms like Harper and Vercel will be crucial. Staying informed about the latest releases and performance benchmarks can help you make informed decisions about your architecture strategy.

For more insights into choosing the right technologies for your projects, you might find our articles on Understanding When to Use React vs Next.js in Projects and Configuring Node.js Environments: Local to Production useful.