Co-located vs. Distributed Architectures: HarperDB's Approach to Personalized Data
This article discusses HarperDB's argument for a single-runtime, co-located architecture that keeps application code and data together, contrasting it with the prevalent multi-system, decoupled approach seen in serverless stacks like Vercel. It highlights the performance benefits of in-process data access for personalized data workloads, while acknowledging the strengths of distributed systems for cacheable content and high concurrency.
Read original on InfoQ ArchitectureThe article presents HarperDB's architectural philosophy, advocating for a co-located runtime where application code and data reside within a single process. This approach is contrasted with the more common multi-system stack that decouples concerns, typically involving separate databases, caches, and compute layers (e.g., serverless functions).
Architectural Trade-offs: Co-located vs. Decoupled
HarperDB's benchmark against a Vercel-based stack (Vercel Functions, Neon Postgres, Upstash Redis, Ably) illustrates a core trade-off: in-process data access can yield significantly lower latency (0.4ms) compared to network hops between decoupled services (~3ms). This advantage is particularly pronounced for live, personalized-data workloads that require frequent data lookups, as the latency accumulates with each personalized read.
A key tenet of the co-located architecture is that "a personalized read is not a network request to another service; it is a function call against an in-memory table." This minimizes network overhead and simplifies the data path.
- Co-located (HarperDB): Data, compute, and messaging are in one system. Wins for live, personalized data paths (single reads, injected live values, server-side streaming, write-to-read freshness, read fan-out at normal load) due to in-process memory access.
- Decoupled (Vercel stack): Separate serverless functions, remote database, cache, and real-time services. Wins for cacheable content (leveraging CDNs) and broadcast-only real-time. Better for high, sustained fan-out loads due to serverless autoscaling.
Performance Implications and Workload Dependency
The article emphasizes that the optimal architecture is workload-dependent. While HarperDB excels in scenarios demanding low-latency access to personalized, dynamic data, serverless stacks with robust CDNs are superior for delivering static or highly cacheable content at scale. High concurrency fan-out also favors serverless autoscaling where a single co-located node might hit throughput ceilings.
HarperDB's recent 5.2 release includes a new record cache and independent commit paths, addressing earlier issues where heavy writes could starve unrelated work within the shared process. This evolution shows an ongoing effort to optimize the co-located model for diverse workloads while maintaining its core advantages.