DEV Community

Cover image for Vault Performance Benchmarks: What Breaks First at Scale
shalini-thomas
shalini-thomas

Posted on • Originally published at hashicorp.com

Vault Performance Benchmarks: What Breaks First at Scale

Vault deployments usually start small, a handful of services pulling secrets. As adoption grows, more systems lean on Vault for authentication, secret retrieval, and certificate issuance, and concurrency climbs with them. We ran a series of benchmarks on Vault Enterprise (self-managed) to see what actually breaks first at scale, not just in theory.

How we tested

All tests ran on a HashiCorp Validated Design deployment on AWS, Vault Enterprise 1.17.3+ent with integrated Raft storage. Load was generated with k6, ramping from 1 virtual user up to 500 for KV workloads, and up to roughly 200 to 300 VUs for SSH and PKI depending on the operation.

What we found

Reads consistently outperformed writes, roughly 2.3x faster, since writes have to commit and replicate across the Raft cluster while reads don't carry that overhead.
Payload size mattered more than expected. 1 KB reads scaled cleanly to 500 VUs with no saturation. 1 MB reads dropped to single digit requests per second under the same load, since larger payloads mean more disk writes and more Raft replication overhead.
Memory turned out to be the real ceiling, not CPU. CPU stayed in the 20 to 40 percent range even at peak concurrency, but memory hit 100 percent utilization at 500 concurrent users, making it the most binding constraint we observed.
For SSH certificate signing, algorithm choice changed scalability substantially. ED25519 pushed the concurrency knee point to roughly 200 VUs, about double what RSA-2048 handled, while using a fraction of the CPU, around 40 percent versus 92 to 96 percent for RSA at comparable load.
PKI workloads hit latency limits earlier than KV, with the knee point around 25 concurrent users for certificate issuance, and revocation operations starting to time out as concurrency approached 200.

What this means operationally

Keep secret payloads small where possible, ideally under 100 KB. Invest in storage with strong write throughput and fast fsync performance, since Raft write commits depend on it. Plan memory capacity ahead of concurrency growth, not just CPU. And for SSH-heavy environments, ED25519 buys meaningfully more headroom than RSA-2048 at the same infrastructure cost.

Full methodology, all five findings, and the complete benchmark charts are in the original piece on HashiCorp's blog: https://www.hashicorp.com/en/blog/understanding-vault-performance-benchmarks-from-real-world-workloads

Top comments (0)