Standby vs Performance Standby in HashiCorp Vault: HA is not the same as read scaling

A three-node Vault cluster is often described as “one active and two standby nodes.” That is correct, but it leaves out the most important design question: what can those standby nodes actually do when client traffic reaches them?

With a regular standby, the answer is mostly forward it. With a performance standby, the answer can be serve it locally — but only when the request does not modify Vault's underlying storage.

That distinction is the difference between high availability and high availability plus horizontal read scalability.

The big picture

In an HA cluster there is still only one active node. The active node is the authority for operations that change Vault's persistent state. Other nodes remain standby members of the same cluster.

How the request paths differ

Regular standby: HA without horizontal request processing

Assume a load balancer sends an application request to a regular standby node. The standby is unsealed and part of the HA cluster, but it does not process that client request as an independent serving node.

With Vault request forwarding enabled, the standby sends the request to the active node over Vault's cluster communication channel. The active node performs the operation and the response returns through the node that originally accepted the client request.

If request forwarding is not being used, a standby can instead respond with an HTTP 307 redirect to the active node.

The operational consequence is important: if 1,000 reads are distributed across three nodes but Nodes 2 and 3 are ordinary standbys, the active node ultimately performs those requests. The extra nodes increase availability, not horizontal request-processing capacity.

Performance standby: HA plus read scaling

A performance standby is still a standby member of the same cluster. The difference is that it first attempts to process an incoming request locally.

If the operation can be completed without changing Vault storage, the performance standby serves it directly. If Vault detects that the operation requires a storage write, the request is forwarded to the active node.

This is why performance standbys can provide near-linear improvement for many read-heavy workloads: the load is no longer forced through a single active process for every request.

It is not GET versus POST

This is the easiest point to misunderstand.

Vault does not decide “read-only” based on the HTTP method. The real question is: does this operation modify Vault's persistent storage?

A Transit encryption call is normally a POST, but ordinary encrypt/decrypt operations do not modify the Transit key configuration or create a Vault lease. A performance standby can therefore process them locally.

What usually runs locally?

A typical three-node Vault Enterprise design

All three nodes remain members of the same Vault cluster. With Integrated Storage, each node has a local copy of the Raft data. Only the active node commits writes; the resulting changes are then replicated to the other nodes.

Performance standby behavior is separate from Raft voting. A standby can be a voting member or, in Enterprise designs that use non-voters for additional read capacity, a non-voting member. A normal voting performance standby is eligible to participate in leader election; a non-voter is not there to increase quorum.

What happens if the Active node fails?

Before failure

Vault-1 = Active
Vault-2 = Performance Standby
Vault-3 = Performance Standby

Vault-1 fails
        |
        v
Raft leader election

After election

Vault-1 = Down
Vault-2 = Active
Vault-3 = Performance Standby

The newly elected active node now becomes the authority for storage-changing requests. The remaining eligible standby continues operating as a performance standby.

So, in a conventional three-voter cluster, performance standbys preserve the same failover model while adding local read-processing capacity before a failure occurs.

How do I verify a performance standby?

Do not expect vault status to say:

HA Mode = performance standby

A performance standby is fundamentally still a standby. A status output looks conceptually like:

HA Enabled                          true
HA Mode                             standby
Active Node Address                 https://vault-1.example:8200
Performance Standby Node            true
Performance Standby Last Remote WAL ...

That last pair of fields is the useful distinction.

The load balancer is part of the scaling design

Performance standbys only provide horizontal read scaling if client traffic can actually reach them.

If the load balancer expects an HTTP 200 health result, HashiCorp documents:

/v1/sys/health?perfstandbyok=true

for performance standbys. If ordinary standbys also need to be considered healthy by a monitor that only accepts 200, standbyok=true is the corresponding control for regular standbys.

Performance standbys and Integrated Storage consistency

Horizontal reads introduce an important trade-off when Vault uses Integrated Storage.

The active node writes to its local Raft state and the new state is then propagated to the other nodes. For a short interval, a performance standby can have an older view than the active node. That means a write followed immediately by a read routed to a performance standby can encounter a read-after-write consistency window.

Vault has mechanisms to deal with this. Storage-changing responses can return an X-Vault-Index, and a later request can supply that index together with an inconsistency-handling instruction so a node that has not yet observed the required state can forward the request to the active node.

X-Vault-Index: <index from the write response>
X-Vault-Inconsistent: forward-active-node

This preserves stronger client expectations where they matter, but there is a performance trade-off: the more often requests need to be conditionally forwarded to the active node, the less horizontal read scaling the performance standbys can provide.

What actually becomes the bottleneck?

Performance standbys do not make the active node irrelevant. The active node is still responsible for storage mutations.

Workloads dominated by these operations still concentrate work on the active node:

• authentication and service-token creation,
• dynamic secret generation,
• lease creation, renewal and revocation,
• secret writes,
• many PKI issuance workflows.

That is why adding performance standbys to a write-heavy workload may not produce the same scaling result as adding them to a KV-read or Transit-heavy workload.

Performance standby is not performance replication

The names sound similar, but they solve different scaling problems.

Operational notes

• Performance standby is normally automatic when entitled. Vault enables the feature when the Enterprise license includes it.
• Keep configuration consistent. If disable_performance_standby is used, HashiCorp recommends keeping that setting consistent across cluster nodes.
• Do not confuse standby role with voting status. Performance behavior controls request handling; voting/non-voting status controls Raft quorum and election participation.
• Monitor the right things. Node role, health code, replication/WAL progress, active-node saturation and forwarded-request rate all matter more than simply counting servers.

When do performance standbys make sense?

The simplest way to remember it

Regular standby: “I am ready to become Active, but until then I forward client work.”

Performance standby: “I am ready to become Active, and while I am waiting I can independently serve requests that do not require a Vault storage write.”

That is the architectural difference. Both strengthen availability. Only the performance standby turns otherwise-idle standby compute into useful request-serving capacity.

Further reading

• HashiCorp Vault — Performance standby nodes
• HashiCorp tutorial — Scale horizontally with performance standby nodes
• HashiCorp Vault — High availability internals
• HashiCorp Vault API — /sys/health
• HashiCorp Vault — Data consistency
• HashiCorp Validated Designs — Vault VM detailed design

Questions or corrections? Feel free to send me a note.