Which OpenBao storage backend fits your team
A team choosing storage for a new OpenBao cluster should start with the operations skills it already has. OpenBao's storage documentation marks both Integrated Storage (Raft) and PostgreSQL as production ready with high availability, so neither option is the unsafe choice. The difference is who runs the replication. With Raft integrated storage, OpenBao keeps a replicated copy of its data on every node and the cluster manages quorum itself, so you need no external database. The OpenBao docs also recommend PostgreSQL for operators new to OpenBao, describing it as the easier backend to operate safely, so a team without prior OpenBao storage experience should weigh that advice heavily before choosing Raft.
Raft suits a team that wants no external database tier to back up, patch and monitor, and that is comfortable owning node joins, cluster_addr networking and manual unseal after restarts under a Shamir seal. Keep the Raft option when your nodes can reach each other reliably and you can test node replacement before go-live. PostgreSQL suits a team that already runs PostgreSQL well, with tested backups, point-in-time recovery and a monitoring habit, because OpenBao then stores its openbao_kv_store and openbao_ha_locks tables in a database your staff already know. Read scaling is the deciding factor for some teams: standbys serve read-only operations on Raft since v2.5.0, and v2.7.0 extended that to PostgreSQL, but PostgreSQL read scaling requires physical replication and the docs recommend sslmode set to verify-full. Confirm the physical replication design with your DBA before you commit to it.
Raft and PostgreSQL storage compared factor by factor
This table compares Raft integrated storage and PostgreSQL as storage backends for an OpenBao cluster, row by row on status, scaling, network, replication, tables, failover and tuning. Read each row as a checklist of what you must configure and operate, and confirm the items marked for vendor confirmation before you commit to a design.
| Factor | Raft integrated storage | PostgreSQL storage |
|---|---|---|
| Production status | Documented as production ready with high availability and horizontal read scalability | Documented as production ready with high availability and horizontal read scalability |
| HA and read scaling | HA and horizontal scaling since v2.5.0; Raft standbys serve read-only operations | HA and horizontal scalability since v2.7.0; read scaling requires physical replication |
| Project recommendation for new operators | Harder to operate safely than PostgreSQL, per the OpenBao storage docs | Recommended as the easier backend to operate safely for operators new to OpenBao |
| Network requirements | Requires cluster_addr for communication between Raft nodes | Requires a reliable database connection; docs recommend sslmode verify-full |
| Replication model | Replicated copy of OpenBao data on every node via Raft consensus | Data lives in PostgreSQL; replication is handled by PostgreSQL itself |
| Tables created | Raft data is kept inside OpenBao nodes, with no separate database tables | Creates openbao_kv_store and, when HA is enabled, openbao_ha_locks |
| Failover ownership | OpenBao Raft handles leader election among voting nodes | PostgreSQL does not detect primary failure; confirm which external tool will promote a standby |
| Required tuning | Set performance_multiplier to 1 for production; no separate ha_storage backend | Confirm replication mode, disable_standby_reads for logical replication, and connection settings |
| Node joining | Nodes join through retry_join or cloud auto_join; Shamir-sealed nodes need manual unseal | Nodes connect to the same database endpoint; confirm how your cluster is load balanced |
How Raft integrated storage keeps data replicated across nodes
Raft integrated storage keeps a full, replicated copy of OpenBao's data on every node, and the nodes agree on each write through the Raft consensus algorithm. There is no separate database to run. The cluster itself is the storage layer, so the team that operates OpenBao also owns replication, quorum health, snapshots and recovery. Every node needs a reachable cluster_addr so Raft peers can talk to each other, and that address must be planned into your firewall and load balancer rules before the first node starts.
Nodes join the cluster through retry_join stanzas that list the peers to contact, or through cloud auto_join where the provider's tags or metadata identify the peers. A node joined under Shamir seal still needs to be unsealed manually after each restart, so the unseal procedure and key custody must be in the runbook before go-live. If you need read scale beyond the quorum, retry_join_as_non_voter adds nodes that replicate data and can serve read-only operations without voting, which keeps the voting set small enough to commit writes quickly.
Integrated Storage cannot be combined with a separate ha_storage backend, so the cluster's storage and HA coordination both live in Raft. Before choosing this path, confirm with your platform team that they can run a Raft quorum across failure domains, monitor peer health, rehearse node replacement and restore from snapshot, and set performance_multiplier to 1 as the OpenBao Raft documentation recommends for production. Review the OpenBao Integrated Storage documentation against your exact release line before finalizing the design.
Four decisions that point to one backend
Four factors usually settle the choice between Raft and PostgreSQL before any performance testing begins. Each one points toward a backend under a specific condition, so the team should score its own situation against all four before committing.
Existing PostgreSQL operations skill
If your database team already runs PostgreSQL for backup, patching, replication and restore, PostgreSQL storage moves OpenBao's data into a system those people operate every week. OpenBao's storage documentation recommends PostgreSQL to operators new to OpenBao as the easier backend to operate safely. Check whether the team has tested a restore of the OpenBao tables, not only of other databases, and who owns the failover tooling, since PostgreSQL does not detect a primary failure on its own.
Appetite for running consensus
Integrated Storage replicates the full OpenBao dataset to every node through the Raft consensus algorithm, so the cluster itself carries the replication work. Teams that want no extra database tier and are comfortable operating a small quorum with cluster_addr between nodes will find Raft simpler to keep in one place. Teams that do not want to learn quorum behavior, node join and manual unsealing after restarts should weigh that against the operating model of a shared database they already support.
Horizontal read scaling needs
If many clients read secrets from standby nodes, the replication model matters. Raft standbys have served read-only operations since v2.5.0, and PostgreSQL gained the same horizontal read scaling in v2.7.0, but PostgreSQL needs physical replication for it, and logical replication requires disable_standby_reads. Confirm which replication mode your database platform supports, and whether your network allows the connection to be encrypted with sslmode set to verify-full.
Air-gapped sites or no database team
In an air-gapped network or a site without a database team, an external PostgreSQL server adds a system that must be built, patched, backed up and monitored inside the isolated boundary. Raft keeps storage inside the OpenBao nodes, which can reduce the number of moving parts to approve and maintain. If the site already has a supported PostgreSQL service with tested backups, that service may carry the load. Ask who will perform restores and upgrades before choosing, because each option moves that work to a different team.
Tuning each backend needs different settings
Raft keeps a replicated copy of OpenBao's data on every node, so the tuning work centers on cluster membership and performance. Nodes must be able to reach each other on the address set in cluster_addr, and the cluster must be able to elect a leader, which depends on how many voting members you run and where they sit. The OpenBao Raft documentation recommends a performance_multiplier of 1 for production, which selects the highest-performance timing. Nodes join through retry_join stanzas or cloud auto_join, and a node joined under a Shamir seal still needs manual unsealing after it starts.
- performance_multiplier of 1: The documentation recommends this value for production. Lower timing values make leader elections faster but raise the risk of false elections on a slow network.
- retry_join configuration: List every intended peer, and confirm each address resolves and is reachable from every node before you rely on automatic joining.
- Voter placement: Voting members form the quorum. Spread them across failure domains and keep the voter count consistent with the failure tolerance you have designed for.
- Non-voter placement: Set
retry_join_as_non_voteron nodes that should add read scalability without affecting quorum. Non-voters do not change how many failures the cluster can survive. - No separate ha_storage: A separate ha_storage backend cannot be declared alongside Integrated Storage, so remove any leftover stanza when you migrate a configuration.
Confirm with your OpenBao support path how many voters and non-voters your topology needs and how your network team will validate latency between sites.
With PostgreSQL, OpenBao stores data in the openbao_kv_store table and, when HA is enabled, uses openbao_ha_locks for coordination. The tuning work moves to the database: transport security, replication topology, read behavior on standbys and connection handling. The OpenBao documentation recommends sslmode set to verify-full for the database connection, which checks both the certificate chain and the server name. Horizontal read scalability needs physical replication, and logical replication requires disable_standby_reads.
- sslmode verify-full: Use this setting in the connection string so OpenBao validates the database server certificate and host name rather than trusting any certificate.
- Replication setup: Read scalability depends on physical replication to standby servers. Confirm the replication mode you choose (synchronous or asynchronous) and how it affects commit latency and data loss exposure.
- disable_standby_reads for logical replication: If you use logical replication, set
disable_standby_readsas the documentation requires. Plan this before you enable standby reads anywhere else in the topology. - Failover tooling: PostgreSQL does not detect a failed primary or promote a standby by itself, so you need external failover software and a tested runbook.
- Connection pooling with PgBouncer: PgBouncer is a common option for limiting database connections. Confirm with OpenBao and your DBA whether it fits the session behavior your deployment needs before you place it in the path.
Ask your database team to confirm the replication mode, failover tool and certificate chain before the first production load.
Some tuning choices apply to both backends even though the mechanics differ. Both backends need a deliberate HA design, both support read-only standbys in current OpenBao releases, and both depend on the network path between nodes or between OpenBao and the database. Teams often tune one backend and then carry assumptions across to the other, which is where most misconfiguration comes from. Review these points as one checklist before you sign off a topology.
- Standby read behavior: Since OpenBao 2.5.0, Raft standbys can serve read-only operations, and v2.7.0 extended this to PostgreSQL. Test which read paths your applications use before you send them to standbys.
- Network validation: Measure latency and packet loss between nodes or between nodes and the database under realistic load, not only at install time.
- Seal planning: Storage tuning does not replace a seal decision. Plan how nodes are unsealed after restarts, especially if you use Shamir shares.
- Upgrade order: Record the exact OpenBao version and the backend version (PostgreSQL 14 through 18 are current major versions) so upgrades of each component are planned separately.
- Documented test restores: Rehearse restoring data and rejoining a node, since the recovery steps differ between the two backends.
Ask your implementation partner for a written tuning baseline that names the settings above, and verify them in a non-production cluster first.
Questions teams ask before choosing OpenBao storage
Which OpenBao storage backend is easier to operate for a new team?
The OpenBao storage documentation recommends PostgreSQL to operators new to OpenBao, describing it as an easier backend to operate safely than Raft. Both backends are marked production ready with high availability. The practical difference is where the operational work sits. With Raft, the OpenBao nodes themselves hold the replicated data, so your team must manage node membership, cluster_addr networking between nodes, snapshots and recovery of the Raft quorum. With PostgreSQL, your team operates a database server or cluster it may already run, using tooling it may already know, while OpenBao only needs a connection. If your organization has no PostgreSQL practice, that advantage shrinks, and Raft may be the simpler path to own.
What does each storage backend cost in effort, and who gets paid for it?
Neither OpenBao nor PostgreSQL carries a license fee for this choice: OpenBao is MPL-2.0 and PostgreSQL uses the PostgreSQL License. The cost is labor and infrastructure. With Raft, the work is building and running the OpenBao cluster, sizing its nodes and testing failover. With PostgreSQL, the work is the database platform, including backups, replication, failover tooling and upgrades, which PostgreSQL itself does not automate: its documentation states that automatic failover needs external tools. One-time costs include design, initial build and migration. Recurring costs include patching, upgrades and on-call time. Ask any vendor or partner for a quote that separates design, build, testing, documentation and ongoing support, and state which of those you already staff internally.
Can an in-house team run OpenBao Raft or PostgreSQL storage alone?
Often yes, if the team already runs the underlying skill. A team that operates PostgreSQL clusters in production can usually extend that practice to OpenBao storage, provided it has tested failover, backups and restores. A team without distributed-systems experience should weigh Raft more carefully, because quorum loss, node replacement and seal handling are the failure modes that need rehearsal. Before deciding, check whether your team has run a restore drill, a failover drill and a seal recovery drill in a non-production environment. If any of those are missing, the gap is the scope to cover, either internally or through a fixed-scope engagement.
How long does migrating OpenBao storage take?
No duration fact is supplied for this migration, so no timeline can be stated here. Ask for one only in writing, based on your environment. The main drivers are the data volume, whether the migration needs downtime, the number of clusters and environments, how many dependent applications and auth methods must be retested, and whether your change process requires approvals and a rollback window. Check the OpenBao migration guide and the storage documentation for the exact steps that apply to your current version before estimating. A small test cluster copied from production often shows the real effort faster than any estimate.
Does PostgreSQL's license or support window change the decision?
The license rarely decides the question, because PostgreSQL's license is liberal and imposes no fee on the database itself. The support window matters more. PostgreSQL supports each major version for 5 years after its initial release, and the supported list includes 14, which the versioning policy lists as supported until November 12, 2026. Your database team must plan major upgrades on that cadence, using pg_upgrade, dump and restore, or logical replication. Raft has no separate database upgrade path, but OpenBao upgrades still need a plan. Confirm the PostgreSQL version your platform team will support before choosing this backend, and check the policy as dates approach.
What network and replication setup does each backend need?
Raft needs reliable connectivity between OpenBao nodes, with cluster_addr configured for node-to-node traffic, and an odd number of voting nodes for quorum. Joining nodes use retry_join or cloud auto_join, and nodes under a Shamir seal still need manual unsealing. PostgreSQL needs a primary and standbys, and horizontal read scaling requires physical replication. Logical replication requires disable_standby_reads, and the docs recommend sslmode set to verify-full for the database connection. Your network team must also decide how clients reach the active node and how failover is detected. Review both configuration pages with your architects before committing.
When should we ask DeployOpen for a fixed-scope quote?
Ask when you have decided on a backend, or narrowed the choice to two, and can describe your current state: OpenBao version, existing PostgreSQL or Raft experience, seal method, network topology and the environments that need migration. DeployOpen plans, implements, hardens, backs up and documents self-hosted platforms inside your own infrastructure, and most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. DeployOpen does not publish a price list, so a quote follows from that written scope. Expect the scope to include design review, build, failover and restore testing, documentation and handover, and ask whether ongoing support is needed as a separate retainer.
Upgrades, backups and monitoring for each backend
This table compares how each OpenBao storage backend is upgraded, backed up and monitored, and what skills each one asks of your team. Read it as an operating checklist: the Raft column is about managing peers inside OpenBao, the PostgreSQL column is about managing a database that OpenBao depends on. The main takeaway is that PostgreSQL moves more of the operating burden onto database skills your organization may already have.
| Area | Raft integrated storage | PostgreSQL storage |
|---|---|---|
| Upgrade unit | OpenBao nodes, rolled one at a time while the cluster keeps quorum. Confirm the rolling sequence against the OpenBao release notes for 2.7.1 or 2.6.4 before you start. | PostgreSQL server (minor) and database cluster (major). OpenBao is upgraded separately from the database engine. |
| Minor updates | Replace the OpenBao binary on each node and restart it. Check peer health between steps. | Minor PostgreSQL releases do not change the storage format, so updating means replacing executables and restarting. |
| Major or storage-level upgrades | Handled by OpenBao version changes and migration guidance. Confirm the supported path with the OpenBao migration guide. | Use pg_dumpall and restore, pg_upgrade, or logical replication. Logical replication allows major upgrades with only several seconds of downtime, according to PostgreSQL's upgrading documentation. |
| Backup responsibility | Your team owns snapshots of Raft data and the seal and recovery material. Confirm how snapshots are taken and restored in your environment. | Your database team owns base backups and WAL archiving for point-in-time recovery. OpenBao data sits in openbao_kv_store, so backups must cover that table. |
| What to monitor | Raft peer membership, leader stability, voter and non-voter status, and whether standbys are current. | Replication lag on standbys, connection counts, the openbao_ha_locks table when HA is enabled, and disk growth. |
| Failover | Raft elects a new leader among voting peers. Confirm the quorum size you need for your node count. | PostgreSQL does not detect primary failure on its own, so you need external failover tooling and its testing. |
| Skills required | Operators who understand Raft consensus, peer joins, and OpenBao cluster configuration such as cluster_addr. | Database administrators comfortable with replication, backup tooling, and PostgreSQL upgrades, plus OpenBao configuration for the connection. |
What switching backends later involves
Moving an OpenBao cluster between Raft integrated storage and PostgreSQL is a storage migration, not a configuration edit. The storage stanza decides where every secret, lease and policy is written, so changing it means moving the entire dataset, re-establishing HA coordination and re-testing unseal and recovery on the new backend. Before any work begins, read the OpenBao migration guide at OpenBao migration guide and confirm with OpenBao that the path you intend to take is supported for your exact release line, since that guide covers a Vault to OpenBao binary swap and may not describe a Raft to PostgreSQL move. Ask whether they publish a tested procedure for that direction before you commit to a design.
Plan the backup and rollback first. Take a full, restorable backup of the cluster and verify that you can restore it into a scratch environment, including the unseal material your seal type requires. Record the current cluster_addr, retry_join settings and any ha_storage configuration so you can reproduce the existing topology if the move fails. Decide in advance how you will return to the original backend, how long the original stays intact, and who signs off on the cutover. Because switching later can involve a maintenance window, a rehearsal in a non-production cluster that mirrors your node count and network paths is the most useful check you can run. Ask DeployOpen or your internal platform team to include rollback steps in the written scope, so the switching cost is visible before you pick a backend.
Treat the switching decision as a long-term commitment. If your team expects to grow beyond a few nodes, or may later want the operational model of the other backend, record that now and weigh it against the cost of a future migration. Confirm with OpenBao which storage features, such as read scaling on standbys, are available on each backend in the release line you will run, because a migration can also change the behavior your applications depend on. Document the decision, the tested migration path and the rollback plan in the same runbook as your unseal procedure.
How DeployOpen scopes and runs OpenBao storage deployments
DeployOpen plans, implements, hardens, backs up, documents and supports self-hosted open-source platforms inside the client's own infrastructure, so the storage choice is made against that environment rather than in the abstract. Each engagement starts with a written scope that records which backend fits the client's network, team and recovery goals.
How we scope
- Written scope records the chosen storage backend, the node count and the failure scenarios it must survive.
- Scope covers network paths between OpenBao nodes, including cluster_addr reachability and firewall rules.
- Scope states who operates the database or Raft cluster after handover and what skills that team must have.
How we build
- Build covers the storage configuration, seal setup and HA join method for the agreed backend, in the client's own environment.
- For PostgreSQL, build includes replication topology, sslmode verify-full settings and the failover tooling the client selects.
- For Raft, build includes retry_join or auto_join configuration, performance_multiplier settings and unseal procedures for each node.
How we hand over
- Handover includes runbooks for node replacement, restore testing, backup scheduling and rollback to the prior configuration.
- Documentation records the configuration files, the ports and certificates in use, and the tested failover steps.
- Each deliverable is listed in the written scope so the client can confirm what was built before work closes.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Upgrade planning covers OpenBao release lines and the supported PostgreSQL major version that the client runs.
- Ask for the retainer terms, response expectations and test cadence in writing before committing to a support model.
