storage stanza

The storage stanza configures the storage backend, which represents the location for the durable storage of OpenBao's information. Each backend has pros, cons, advantages, and trade-offs. For example, some backends support high availability while others provide a more robust backup and restoration process. For information about a specific backend, choose one from the navigation on the left.

Configuration

Storage backend configuration is done through the OpenBao configuration file using the storage stanza:

storage [NAME] {
  [PARAMETERS...]
}

For example:

storage "raft" {
  path = "/mnt/openbao/raft"
}

or:

// Set BAO_PG_CONNECTION_URL=postgres://postgres:postgres@localhost:5432.
storage "postgresql" {
  ha_enabled = true
  max_connect_retries = 50
}

For configuration options which also read an environment variable, the environment variable will take precedence over values in the configuration file.

Integrated Storage (Raft) vs. PostgreSQL

It is recommended to evaluate both storage engines on their merits and choose the best for your needs. If you're new to running OpenBao, we recommend PostgreSQL as an easier storage backend to safely operate than Raft.

The table below compares the characteristics of Integrated Storage and PostgreSQL.

	Integrated Storage (Raft)	PostgreSQL
Production Ready	Yes	Yes
Operation	Operationally simpler to setup with no additional software installation required. Operator experience with Raft is highly recommended; refer to OpenBao's documentation for more information. OpenBao requires special operations to join, manage, and failover nodes using the Raft backend.	Must install and configure the external storage environment outside of OpenBao. For high availability and horizontal scalability, PostgreSQL should be clustered. OpenBao requires no special operation beyond a PostgreSQL connection URL to join, manage, and failover nodes with a PostgreSQL backend.
Networking	One less network hop: data is stored locally resulting in better read performance. Write performance is more limited as all nodes must vote to agree on a write, resulting in more latency-sensitive network traffic.	Extra network hop between OpenBao and PostgreSQL if not co-located. Reads are cached by default unless disable_cache=true is specified. However, PostgreSQL can often have better write performance than Raft as it has a single active node which mirrors writes to followers.
High Availability and Disaster Recovery Support	Yes, with horizontal scalability (read).	Yes, with horizontal scalability (read).
Troubleshooting and Monitoring	Integrated Storage is a part of OpenBao; therefore, OpenBao is the only system you need to monitor and troubleshoot. However, Raft and BBolt failure modes can often be complex or require specialized expertise to troubleshoot and snapshots to recover from.	The source of failure could be the external storage; therefore, you need to check the health of both OpenBao and the external storage. This requires expertise in the chosen storage backend and additional monitoring of that storage.
Data Location	The encrypted OpenBao data is stored on the same host where the OpenBao server process runs. This makes it slower to horizontally scale on compute-heavy workloads as data must also be replicated.	The encrypted OpenBao data is stored where the external storage is located. Therefore, the OpenBao server and the data storage may be hosted on physically separate hosts. This may make it faster to horizontally scale OpenBao on compute-heavy workloads as existing database nodes may be used.
System Requirements	Avoid "burstable" CPU and storage options due to the latency sensitive nature of this backend. SSDs should be used for the hard drives.	Follow the system requirements given by your chosen storage backend and size OpenBao nodes according to compute complexity.