Harper 5.2 improves the economics and reliability of demanding workloads in two ways: repeated reads and supported indexed queries can serve more traffic on the same hardware, while more production responsibilities can run inside the Harper runtime.
For teams responsible for application performance, infrastructure cost, and operational complexity, those improvements affect both sides of the architecture equation. The database does less work to answer common requests, and the application needs fewer surrounding systems to run in production.
Everything covered below is available today. Review the complete list of additions and fixes in the Harper 5.2 release notes.
Serve the same traffic on less hardware
For many applications, repeated reads account for a large share of request volume.
Product catalogs, personalized page data, session information, permissions, and entitlement state may be requested thousands of times while changing much less frequently.
Harper 5.2 adds a record cache that allows repeated reads to skip the storage layer while still ensuring that the returned record is current. In Harper’s benchmarks, warm reads ran between five and eight times faster.
The same mechanism improved vector-search performance by approximately 2.6 times in the tested workload. For agentic and retrieval-augmented applications, that can reduce retrieval latency and improve the infrastructure efficiency of building context for a model.
The practical result is a choice. A team can serve its existing traffic on a smaller footprint or retain the same footprint and absorb a larger peak without changing the application.
Cold reads are unchanged because the first request still needs to retrieve the record from storage. The performance gain appears in repeated-access patterns, which are common in production applications.
Heavy writes no longer stall unrelated asynchronous work
Average latency tells only part of the story. Production incidents are often driven by tail latency: the small percentage of requests that become slow during a traffic peak or a heavy write burst.
In earlier Harper versions, database commits competed for a shared pool of worker threads with other asynchronous work in the process. Under sustained write pressure, unrelated operations could queue behind database commits and experience increased latency.
Harper 5.2 gives each database its own commit path.
Raw commit throughput remains approximately the same. The difference is isolation: heavy commit activity no longer occupies the same shared path as unrelated asynchronous work.
This improvement matters most when the system is already under pressure. It helps preserve more consistent application behavior during write-heavy periods, when predictable latency is both most valuable and most difficult to maintain.
Supported indexed queries no longer need to scan the full table
Harper 5.2 makes a new SQL engine the default. Rather than routing every query through a generic execution layer, the new engine plans supported queries directly against Harper’s indexes and falls back automatically for query shapes it does not yet support.
The effect is easiest to see in a query that should be inexpensive.
In the benchmark, retrieving ten records by primary key from a table containing 40,000 records took 133.6 milliseconds through the previous query path. The same request took 1.65 milliseconds through the new engine because the indexed path avoided scanning the table.
All 16 supported query shapes included in the benchmark completed faster, with results verified as identical between the two engines.
The important change is the shape of the cost curve. Supported queries that previously scanned a full table can now perform work based on the range actually requested. In the benchmark, the execution time for the tested range query remained nearly flat as the table grew from 1,000 to 40,000 records.
That allows applications to grow without automatically turning common queries into future re-architecture projects.
Keep application secrets encrypted through deployment
Applications increasingly depend on credentials for model providers, payment services, messaging platforms, internal APIs, and other external systems.
Those credentials need to reach the running application without appearing in logs, configuration-management traffic, replication payloads, or deployment workflows that were never designed to handle plaintext secrets.
Harper Pro can now encrypt environment-secret values before they leave the client. The values remain encrypted as they pass through the Operations API, operation logs, replication, and the application’s .env file. Harper decrypts the value only when loading it into the running application environment.
In a Harper Pro cluster, encrypted values can replicate across nodes without the plaintext value moving between them.
For teams preparing for SOC 2, PCI, or internal security review, this provides a documented control for protecting application environment secrets during deployment and replication. It does not replace every part of an organization’s secrets-management program, but it removes the need to pass plaintext application credentials through ordinary Harper configuration workflows.
Developers can review the technical design for encrypted environment secrets, including the encryption model, client flow, and threat boundaries.
Helping agentic applications reach production
Harper already runs the model layer and agent loop inside the runtime, with a common interface across OpenAI, Anthropic, Amazon Bedrock, Ollama, and custom model backends.
Models can call tools exposed by the application, close to the data, state, and business logic those tools depend on. Harper 5.2 addresses several additional requirements that emerge when an agent moves from a prototype into production:
- Credentials for hosted model providers can remain encrypted through deployment.
- Applications can combine semantic relevance with record-level access filters during retrieval.
- Recurring ingestion, embedding, summarization, and maintenance jobs can run on a schedule without a separate job system.
- Repeated vector searches can benefit from the same record-caching improvements as other read-heavy workloads.
The common alternative is to connect a model framework, vector database, cache, job runner, and separate secret-delivery tooling, then maintain the contracts among them.
Harper lets more of those responsibilities run in the same runtime as the application. That means fewer integration points to build, test, secure, and troubleshoot.
Read more about the Harper models API and built-in agent loop and the supported model backends.
Semantic search that respects who is asking
Vector search is straightforward when every user can access every record. Enterprise data rarely works that way.
Customer information may be scoped by account. Internal documents may depend on department or role. Product results may vary by region, contract, inventory, or entitlement.
Filtering only after a vector search finishes can produce thin results because the traversal may stop before finding enough records that satisfy the application’s restrictions.
Harper 5.2 allows applications to provide synchronous record-level filters that participate during vector traversal. The search can continue looking for nearby records that satisfy both the semantic query and the application’s access policy, subject to its configured search budget.
That supports use cases such as:
- A support assistant that searches customer history without crossing account boundaries
- An internal agent that surfaces only documents available to the requesting employee
- A commerce experience that combines semantic similarity with regional or customer-specific product rules
This moves semantic retrieval and application-level filtering into the same search process rather than requiring a separate post-processing layer.
The Harper schema documentation covers record-level access behavior and schema configuration.
Four production responsibilities Harper can now handle
Each of the following capabilities can reduce the need for a separate service, vendor, or layer of glue code, depending on deployment requirements.
- Scheduled jobs. Recurring synchronization, reporting, embedding refreshes, and cleanup can be declared in component configuration. In a cluster, Harper coordinates execution through leader election, replicated run state, failover, and limited catch-up behavior.
- Backup and restore. Managed RocksDB backups include verification, incremental storage, deletion, purging, and supported restore workflows. Eligible databases can be restored online when no loaded component is using them, while the system database requires an offline restore. Full snapshots can also be streamed to external storage.
- Application routing. Applications can be mounted by hostname, URL path, or both through configuration. The same package can run under different domains and paths without changes to its internal routing logic, and middleware can declare explicit ordering.
- Web application firewall. Harper Pro evaluates IP, method, path, header, and query rules ahead of authentication and application handlers on application-facing worker HTTP traffic. Blocked requests do not reach the application handler. Rules can run in monitoring or shadow modes before gradual activation across nodes, regions, or tags.
These capabilities do not prevent teams from using an external scheduler, backup platform, gateway, or upstream WAF when their architecture requires one. They give teams the option to handle more of that work inside Harper rather than making every requirement a separate infrastructure decision.
On Harper Fabric, the platform manages the underlying deployment infrastructure. For teams operating Harper or Harper Pro in their own environments, each built-in capability is one fewer system they may need to evaluate, integrate, secure, upgrade, and support.
What this adds up to
The changes in Harper 5.2 affect two important parts of an architectural decision.
Cost per unit of traffic can decrease for workloads that benefit from repeated-read caching and supported indexed queries. Those requests require less work from the database, allowing the same hardware to handle more traffic under the tested conditions.
Operational surface area can also decrease because scheduling, backup, routing, request filtering, encrypted secrets, and agent orchestration can operate within the Harper runtime rather than through separate integrations with their own credentials, failure modes, upgrade cycles, and support requirements.
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.
Start on Harper Fabric · Harper on GitHub · Harper 5.2 release notes
.webp)
.jpg)
%20(1).png){kind=icon}
.png){kind=icon}
.png){kind=icon}