ControlPlane Enterprise for OpenBao Selects PostgreSQL As Recommended Storage Engine

Although development of HashiCorp Vault has stagnated in critical areas that operators need to productively manage deployments, ControlPlane and OpenBao have proactively addressed several of Vault’s most requested features. Many are already implemented, including recursive listing and filtering of list responses.
And additional features are on the way, including search for KVv2, a highly requested feature that is currently in early design and development, and a fresh implementation of Vault Enterprise’s Managed Keys as OpenBao’s External Keys in OpenBao v2.7.0.
The primary challenge for operators isn’t represented in API-level changes, but the operational complexity of HashiCorp’s guidance for Integrated Storage and Raft.
For over a decade, HashiCorp Vault has suffered reliability problems because HashiCorp’s bespoke Raft implementation lacked transactions, a cornerstone of database design for decades, despite providing critical infrastructure. Consequently, consistency and reliability in Vault have often felt like a ‘best effort’ endeavour. And Integrated Storage or Consul have caused outages: BBolt brings many unique failure modes, Raft may require manual peers.json adjustment to restore consensus, and Performance Replication sidesteps Raft with a secondary WAL mechanism.
All of this requires companies to employ highly specialised Vault operators.
ControlPlane Enterprise for OpenBao has been built on that history; our experience managing Vault deployments for clients and troubleshooting downtime caused by Raft issues led us to invest in an alternative, PostgreSQL.
The Case for PostgreSQL over Raft
As the top database in StackOverflow’s 2025 survey, PostgreSQL offers proven reliability that Vault lacks. ControlPlane has been engineering PostgreSQL into a first-class data storage engine, delivering horizontal read scalability to achieve full parity with the existing Raft support, better client consistency control semantics, and building an internal test suite to validate the behaviour of various secret engines.
We’ve also been busy validating the behaviour in various real-world scenarios. PostgreSQL-native Performance and Disaster Replication is far superior to manually managing Vault Enterprise replication: operators can rely on their preferred PostgreSQL physical replication semantics, whether CloudNativePG, EDB’s Postgres AI, Patroni, or PostgreSQL’s native replication primitives.
Many of the changes to support PostgreSQL are already in OpenBao v2.6, with full capabilities rolling out in OpenBao v2.7 later this month, September 2026.
Collaborating with Experts
To spearhead this effort, we have been collaborating closely with CloudNativePG experts, including Gabriele Bartolini, VP and Chief Architect of Kubernetes at EDB. Alongside this effort, our security engineering team has developed a new reference architecture for OpenBao built on Kubernetes and PostgreSQL, to be released alongside OpenBao v2.7.
Want to find out more?
If you are ready to learn more about how easy it is to operate ControlPlane Enterprise for OpenBao, backed by PostgreSQL, contact our team today to discuss how we can support you and your organisation.
Additional links
Introduce GRPC-based invalidation mechanism - #3448
Support index headers for consistency in server, api - #3839
Related blogs

HashiCorp Vault - The Exit Guide Conversation

Sovereign Signing: A Self-Hosted Supply Chain with OpenBao, Cosign, and Flux CD
