In this blog post, I will give you an overview of the new Horizontal Scalability feature of OpenBao, its (current) limitations and planned future developments. In the second part, I will show some benchmarks to see in which cases the new feature helps (spoiler: it works best in read-heavy workloads, but doesn't improve write-heavy workloads).
As the OpenBao community starts development on Namespaces and the Horizontal Scalability Working Group has its kickoff, I wanted to take the opportunity to put forward a blog post describing how these two groups' work can compliment each other and provide an alternative path forward other than Vault Enterprise's Performance Secondary and Disaster Recovery clustering modes.
OpenBao, like its upstream, favors the raft internal storage engine.
While more complex than relying on a database for replication, this storage
engine allows us to have lower latency on read operations, because it uses
a local K/V implementation based on B+-trees. For workloads
with low writes but high reads (typical of most uses of K/V secrets), this
trade off allows for the best performance.
An earlier blog post talked about the availability of
transactions in the main branch, this post will focus on
the technical details of implementing transactions.
Recently we merged the last of the transactional storage pull requests, including PostgreSQL support!
OpenBao and upstream lack server-side cross-plugin communication.
As recently seen with an OIDC feature, this shortcoming often needs to be worked around on the client side, potentially exposing sensitive information.
There's usually two paths discussed for cross-plugin communication: