Click Below to Get the Code

Browse, clone, and build from real-world templates powered by Harper.
Comparison
GitHub Logo

Feature Update Replicated Writes

Harper 4.4 introduces a new replication system that boosts replicated write performance by 50% due to optimized direct node-to-node connections.
Comparison

Feature Update Replicated Writes

Harper
at Harper
February 25, 2025
Harper
at Harper
February 25, 2025
Harper
at Harper
February 25, 2025
February 25, 2025
Harper 4.4 introduces a new replication system that boosts replicated write performance by 50% due to optimized direct node-to-node connections.
Harper

4.4 Replication System Update

In Harper 4.4, we introduced a new built-in replication system, “Plexus.” This system provides substantial performance, security, and reliability improvements. Plexus eliminates the need to go through a message broker and instead implements direct connections between nodes. This facilitates optimizations down to the TCP level, highly secure mTLS connection, and robust consistency tracking. This highly optimized system for delivery of replicated writes has yielded significant performance gains. Although many factors create variability in test results, we are confident that results show an average 50% increase in replicated write performance over Harper 4.3.

Interpreting the Benchmark Results

The tests specifically focused on measuring throughput for replicated writes and do not reflect write performance for single standalone nodes. In all, 12 different tests were performed across 4, 5, 6, and 8 node clusters, with all writes fully replicated to all nodes. Tests were further divided into two groups, one with random primary keys (Random IDs) and the second with sequential keys (Sequential IDs), to understand variability across use cases. 


Given the small sample size and the hundreds of potential unseen performance variables at play when using cloud virtual machines, the 6-node Random IDs result was removed after it demonstrated a 121% increase in performance. With outliers removed, the remaining results showed a mean performance improvement of 51% with a standard deviation of 9%.

It is worth noting that sharding was not enabled for these tests. With sharding enabled, higher overall write throughput can be expected across the system, as writes are not committed to each independent node. 

Test Setup

Benchmarks utilized a multi-node Harper cluster and compared database write performance given the following specifications: 

  • Record Size: 400 bytes, 8 fields
  • High concurrency: 500 virtual users writing
  • All writes are new records (inserts) using the POST method of the REST API and are replicated to all other nodes. 
  • ID Specifications: some text
    • Random IDs: Primary keys that are random UUIDs (this is a little slower than sequential IDs, but more reflective of typical usage patterns in practice)
    • Sequential IDs: Primary keys that are sequentially generated.
  • All tests were performed on 16GB Dedicated CPU Compute Akamai Connected Cloud Instances. 
  • The tests used a separate instance for each Harper node and another separate instance to execute the load test runner. 
  • The load tests were performed by k6.

4.4 Replication System Update

In Harper 4.4, we introduced a new built-in replication system, “Plexus.” This system provides substantial performance, security, and reliability improvements. Plexus eliminates the need to go through a message broker and instead implements direct connections between nodes. This facilitates optimizations down to the TCP level, highly secure mTLS connection, and robust consistency tracking. This highly optimized system for delivery of replicated writes has yielded significant performance gains. Although many factors create variability in test results, we are confident that results show an average 50% increase in replicated write performance over Harper 4.3.

Interpreting the Benchmark Results

The tests specifically focused on measuring throughput for replicated writes and do not reflect write performance for single standalone nodes. In all, 12 different tests were performed across 4, 5, 6, and 8 node clusters, with all writes fully replicated to all nodes. Tests were further divided into two groups, one with random primary keys (Random IDs) and the second with sequential keys (Sequential IDs), to understand variability across use cases. 


Given the small sample size and the hundreds of potential unseen performance variables at play when using cloud virtual machines, the 6-node Random IDs result was removed after it demonstrated a 121% increase in performance. With outliers removed, the remaining results showed a mean performance improvement of 51% with a standard deviation of 9%.

It is worth noting that sharding was not enabled for these tests. With sharding enabled, higher overall write throughput can be expected across the system, as writes are not committed to each independent node. 

Test Setup

Benchmarks utilized a multi-node Harper cluster and compared database write performance given the following specifications: 

  • Record Size: 400 bytes, 8 fields
  • High concurrency: 500 virtual users writing
  • All writes are new records (inserts) using the POST method of the REST API and are replicated to all other nodes. 
  • ID Specifications: some text
    • Random IDs: Primary keys that are random UUIDs (this is a little slower than sequential IDs, but more reflective of typical usage patterns in practice)
    • Sequential IDs: Primary keys that are sequentially generated.
  • All tests were performed on 16GB Dedicated CPU Compute Akamai Connected Cloud Instances. 
  • The tests used a separate instance for each Harper node and another separate instance to execute the load test runner. 
  • The load tests were performed by k6.

Harper 4.4 introduces a new replication system that boosts replicated write performance by 50% due to optimized direct node-to-node connections.

Download

White arrow pointing right
Harper 4.4 introduces a new replication system that boosts replicated write performance by 50% due to optimized direct node-to-node connections.

Download

White arrow pointing right
Harper 4.4 introduces a new replication system that boosts replicated write performance by 50% due to optimized direct node-to-node connections.

Download

White arrow pointing right

Explore Recent Resources

Blog
GitHub Logo

5 Architectures for Web Personalization

Personalization is a data-delivery problem. Every architectural choice reduces to two distances: compute to user, and compute to fresh data. This piece maps five real architectures against both axes, scored on a concrete retailer workload where stale or slow data breaks the business.
Blog
Personalization is a data-delivery problem. Every architectural choice reduces to two distances: compute to user, and compute to fresh data. This piece maps five real architectures against both axes, scored on a concrete retailer workload where stale or slow data breaks the business.
Person with short dark hair and moustache, wearing a colorful plaid shirt, smiling outdoors in a forested mountain landscape.
Aleks Haugom
Senior Manager of GTM
Blog

5 Architectures for Web Personalization

Personalization is a data-delivery problem. Every architectural choice reduces to two distances: compute to user, and compute to fresh data. This piece maps five real architectures against both axes, scored on a concrete retailer workload where stale or slow data breaks the business.
Aleks Haugom
Jul 2026
Blog

5 Architectures for Web Personalization

Personalization is a data-delivery problem. Every architectural choice reduces to two distances: compute to user, and compute to fresh data. This piece maps five real architectures against both axes, scored on a concrete retailer workload where stale or slow data breaks the business.
Aleks Haugom
Blog

5 Architectures for Web Personalization

Personalization is a data-delivery problem. Every architectural choice reduces to two distances: compute to user, and compute to fresh data. This piece maps five real architectures against both axes, scored on a concrete retailer workload where stale or slow data breaks the business.
Aleks Haugom
Blog
GitHub Logo

Agentic Engineering Needs an Opinion: Why Scale Starts with Architecture

AI coding works in a sandbox because the environment is trivially narrow. Real systems have history, constraints, and blast radius. Coding agents make sound decisions only when the architecture is explicit and shared. Opinion isn't a constraint on agentic engineering, it's what makes it possible at scale.
Select*
Blog
AI coding works in a sandbox because the environment is trivially narrow. Real systems have history, constraints, and blast radius. Coding agents make sound decisions only when the architecture is explicit and shared. Opinion isn't a constraint on agentic engineering, it's what makes it possible at scale.
A smiling man with a beard and salt-and-pepper hair stands outdoors with arms crossed, wearing a white button-down shirt.
Stephen Goldberg
CEO & Co-Founder
Blog

Agentic Engineering Needs an Opinion: Why Scale Starts with Architecture

AI coding works in a sandbox because the environment is trivially narrow. Real systems have history, constraints, and blast radius. Coding agents make sound decisions only when the architecture is explicit and shared. Opinion isn't a constraint on agentic engineering, it's what makes it possible at scale.
Stephen Goldberg
Jun 2026
Blog

Agentic Engineering Needs an Opinion: Why Scale Starts with Architecture

AI coding works in a sandbox because the environment is trivially narrow. Real systems have history, constraints, and blast radius. Coding agents make sound decisions only when the architecture is explicit and shared. Opinion isn't a constraint on agentic engineering, it's what makes it possible at scale.
Stephen Goldberg
Blog

Agentic Engineering Needs an Opinion: Why Scale Starts with Architecture

AI coding works in a sandbox because the environment is trivially narrow. Real systems have history, constraints, and blast radius. Coding agents make sound decisions only when the architecture is explicit and shared. Opinion isn't a constraint on agentic engineering, it's what makes it possible at scale.
Stephen Goldberg
Blog
GitHub Logo

Building a Cozy Sandbox Game on Harper

A nature-restoration game with six biomes, 150 animals, and a real food web — built with a single Harper component as the entire backend. One YAML file wires the database, API, content seeder, and static host. The same binary ships offline on itch.io.
Shell
Blog
A nature-restoration game with six biomes, 150 animals, and a real food web — built with a single Harper component as the entire backend. One YAML file wires the database, API, content seeder, and static host. The same binary ships offline on itch.io.
Person with long wavy brown hair wearing a bright pink shirt with a teal trim, smiling outdoors in soft sunlight with blurred trees in the background.
Bailey Dunning
Forward Deployed Engineer
Blog

Building a Cozy Sandbox Game on Harper

A nature-restoration game with six biomes, 150 animals, and a real food web — built with a single Harper component as the entire backend. One YAML file wires the database, API, content seeder, and static host. The same binary ships offline on itch.io.
Bailey Dunning
Jun 2026
Blog

Building a Cozy Sandbox Game on Harper

A nature-restoration game with six biomes, 150 animals, and a real food web — built with a single Harper component as the entire backend. One YAML file wires the database, API, content seeder, and static host. The same binary ships offline on itch.io.
Bailey Dunning
Blog

Building a Cozy Sandbox Game on Harper

A nature-restoration game with six biomes, 150 animals, and a real food web — built with a single Harper component as the entire backend. One YAML file wires the database, API, content seeder, and static host. The same binary ships offline on itch.io.
Bailey Dunning
Blog
GitHub Logo

Your Website was Built for Humans. AI Needs Something Cleaner.

The web spent a decade optimizing for browsers. JavaScript-heavy rendering, dynamic CMS templates, and client-side hydration made pages beautiful and machines blind. AI answer engines retrieve, parse, and cite content directly. If your best content is trapped behind a render cycle, a cleaner source wins.
A.I.
Blog
The web spent a decade optimizing for browsers. JavaScript-heavy rendering, dynamic CMS templates, and client-side hydration made pages beautiful and machines blind. AI answer engines retrieve, parse, and cite content directly. If your best content is trapped behind a render cycle, a cleaner source wins.
Person with short dark hair and moustache, wearing a colorful plaid shirt, smiling outdoors in a forested mountain landscape.
Aleks Haugom
Senior Manager of GTM
Blog

Your Website was Built for Humans. AI Needs Something Cleaner.

The web spent a decade optimizing for browsers. JavaScript-heavy rendering, dynamic CMS templates, and client-side hydration made pages beautiful and machines blind. AI answer engines retrieve, parse, and cite content directly. If your best content is trapped behind a render cycle, a cleaner source wins.
Aleks Haugom
Jun 2026
Blog

Your Website was Built for Humans. AI Needs Something Cleaner.

The web spent a decade optimizing for browsers. JavaScript-heavy rendering, dynamic CMS templates, and client-side hydration made pages beautiful and machines blind. AI answer engines retrieve, parse, and cite content directly. If your best content is trapped behind a render cycle, a cleaner source wins.
Aleks Haugom
Blog

Your Website was Built for Humans. AI Needs Something Cleaner.

The web spent a decade optimizing for browsers. JavaScript-heavy rendering, dynamic CMS templates, and client-side hydration made pages beautiful and machines blind. AI answer engines retrieve, parse, and cite content directly. If your best content is trapped behind a render cycle, a cleaner source wins.
Aleks Haugom